[sldev] Packaging the viewer for Linux distributions

[Matthew Wiggins]

Regarding a patching updater for the distributed viewer , there is an  
internal task to do just that, which I've now linked to a related  
PJIRA task: http://jira.secondlife.com/browse/VWR-603. I'm planning  
to resolve this as soon as possible.

As you've rightly pointed out, there is a significant amount of non- 
changing data between releases so we should be able to cut the size  
of updates by a large amount. As Bushing Spatula has found on that  
VVR-603, getting to a 12MB delta is easily achievable. The main  
challenge is producing a system that works on all three platforms in  
a pleasing way for the user, and plays nicely with our versioning  
process.

I'll post more once I've moved onto that task from current bug-fixing  
work.

On 5 Oct 2007, at 13:32, Robin Cornelius wrote:

> On 10/1/07, Bryan O'Sullivan <bos at lindenlab.com> wrote:
>> Callum Lerwick wrote:
>>
>>> Which is why LL should focus on working with Linux distributions  
>>> to get
>>> Second Life into the distributions themselves, rather than  
>>> distributing
>>> binary blobs.
>>
>> We're happy to see people packaging the viewer for different Linux
>> distributions (for example, I'm watching the Fedora packaging tasks),
>> and willing to help out where we can.  I've done quite a bit of  
>> work to
>> make it easier to build a standalone viewer, for example.
>>
>> If there are specific things you'd like to see done, file JIRA tasks,
>> and we'll plug away at them as the opportunity presents itself.   
>> If you
>> want to file an umbrella task and connect the subtasks to it so that
>> it's easier to see which ones are intended to ease distro  
>> integration,
>> all the better.
>
> Coming back to this thread, ATM the viewer is an enormous tar ball and
> I know there are a few of us now doing our own builds with various
> different patchsets for different arch's.
>
> Can we maybe think about splitting up the viewer (distribution) into
> smaller packages. Surely the various artwork and supplied textures
> remain pretty constant and it seems wasteful redistributing the same
> data over and over again.
>
> If we can come up with a basic structure for grouping files then this
> will make packaging the viewer for rpm/deb or even different tar.bz2s
> easier and certainly makes distribution easier. Possibly even on
> windows or mac distribute smaller files or have an automated
> update/installer that can just pull the required package(s).
>
> One of the main questions is anybody have a feel for how static
> various files are. I am sure the various translations and languages
> are being adjusted fairly frequently with addition of new features and
> corrections but what about all the artwork, that must almost be static
> across many versions.
>
> As a bare minimum the viewer splits up into a common arch independent
> package and a  secondlife-official-1.18.4-amd64 etc package, this
> would also allow easy deployment of multiple viewers and 3rd party
> viewers if we all use the same basic system in packages. (Thanks for
> the discussion Julie).  I am wondering if infact it should split even
> further with the language files in one package, various artwork in
> others, main binary in another etc.
>
> I am not sure at this point how this effects anything LL are doing to
> the code base. Its more a policy decision for packagers distributing a
> viewer. For the moment any body have any objections to creating a wiki
> page to outline a packaging policy so at least we can all work from
> the same sheet if we are deploying our own builds of the viewers.
>
> Where it does effect LL is i suppose that we want minimum changes from
> upstream code to the version packaged, so we really don't want to have
> to move files around everywhere and greatly change the code base. So
> to achieve this would require a better build and moving to a more
> standard makefile so we can do various build steps with just make, eg
> make all, make viewer-tarball or what ever? This is quite a big step
> so anybody have any thoughts on that.
>
> Regards
>
> Robin
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html