[sldev] Packaging the viewer for Linux distributions

Robin Cornelius robin.cornelius at gmail.com
Fri Oct 5 05:32:42 PDT 2007


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


More information about the SLDev mailing list