Packaging? Client dependencies?

I know this is far far too early to be asking about this, but at some point we're going to want to package this client up for the various distros out there, and I do not expect Linden will be wanting to make packages available for every packaging system out there. Maybe a .deb since I beleiive Linden use Debian for everything internally.

With that in mind, I'd like to put together a simple ebuild for gentoo, I'll keep it within this forum unless told I can do otherwise, but I'd like to know what dependencies the client has. I figure SDL and X are fairly obvious, along with some version of glibc no doubt.

Are there any more or have LL bundled all the libs with the client. If so what is the position on replacing them with symlinks to the systems own libs. The Gentoo ebuild for Doom3 does this for the bundled libstdc++

I'm hoping when the client matures it'll be able to be installed systemwide and use your home directory for settings and cache like it should. If that happens I might build a Slackware package for it. Having a list of all the dependencies would be nice indeed.

I would say just use autopackage so that it does not matter what distro someone is running.

I'd second the autopackage idea

Anyway, packaging this into distro repositories is absolutely the WORST thing you can do - LL do grid updates which disconnect older clients all the time, and on Windows/Mac use their builtin auto-update system to keep things running smoothly. If the client is installed via rpm, dpkg, portage or whatever then this cannot work. Worse, the moment the distros package maintainer "goes on holiday" or whatever and an update is pushed all the people who installed the client via that mechanism will be locked out of the grid.

This is one of those times when things like the Ubuntu upstream version freeze just doesn't work. Anyway, Linden Labs may not allow it to be repackaged, depends entirely on the EULA on the software. If I was them I'd put a big fat "no inclusion in distros" notice on it, it'll just result in less pain in future for people who aren't super technical and may not turn to the forums for answers when their viewer breaks one day.

Your comment about package maintenance is true, though to a greater or lesser extent depending on the packaging mechanism.

For the "traditional" RPMs on a CD method I agree with you entirely. Within a few weeks of those CDs being shipped, SL is not going to work.

With Apt and Portage it's a lot simpler. I'm fairly certain that LL will be providing an apt repository for the Debian users since LL are apparently Debian based themselves. Maybe these will work on Ubuntu, I don't know.

For Gentoo it's going to be a little different, but unless the specifics of installation change radically with a new release, then repackaging for a version bump is simply a case of changing one line in an ebuild file.

I was just going to post my ebuild here for people to play with, I certainly wasn't going to try and get it included in the main tree or anything.

OK, sure, repositories run by LL themselves would be fine but obviously they'd only cover a small subset of possible users (especially as every distro uses a different depsolver these days). If people want to produce native packages just for testing or personal use them I guess that'd be OK, as long as they come with the relevant warnings ....

Yes it would work for Ubuntu. Well the winehq.com apt repository does anyway.

The WineHQ apt repository also contains packages built specifically for Ubuntu, so that doesn't tell you much. Ubuntu and Debian are not necessarily binary compatible, though for very defensively written code like the Icculus game ports it'd probably work.

Bah. Making an installable binary package out of a pre-built binary package is trivial for package maintainers.

Autopackage on the other hand, fooie. They make a lot of promises that are simply impossible or counter-productive to actually implement, and don't really add anything to the situation aside from a technically tainted package inventory database.

The major problems that are not strictly code-related at the moment are all about library interface compatibility, which is something distro/package maintainers already familiar with the ins and outs of their distro are going to be best able to handle.

Take a look how you installed the NVIDIA drivers, in most cases, it's a package that downloads the code from Nvidia, then puts it in the right place and adds it to the packaging database. Something simular can easily be done for SL

Actually, look at section 2.1.1 in the nVidia licence now. Apparently so long as you don't meddle with the binaries, you're allowed to distribute the thing for Linux yourself now... *sweeeeeet* (Which means that I can finally package the beastie up for Dropline)

I just finished what appears to be a working SL binary package (using some of Lum Kuhr's ideas) for Slackware 10.2 but I'm just stashing it for personal use until I can find out what the licencing rules are.

Hi, I'm a Gentoo developer, and figured I should finally try SL since it was available for now. Apart from a pletorha of bugs, I'm strongly in favour of packaging this up. I would however like to know what versions of all of the bundled libs are being used, to try and avoid the LD_LIBRARY_PATH hackery presently used.

Could somebody from Linden please specify the versions required of each of the included libs?

That way the size of the download can be vastly reduced, and things made to run better in existing package systems.

Actually, you should be able to tell from just looking in the lib/ directory. The packages from the libraries included have been following reasonable guidelines for setting their sonames, so there really shouldn't be any suprises in there. (i.e., if the soname matches, it's *supposed* to "just work" with anything asking for that soname--incompatibilities are supposed to result in a soname change.)

FWIW, the Slackware package I've cobbled up just keeps all the ones LL shipped to ensure there won't even be a chance of some incorrect behaviour cropping up specific to a distro.

I'll try and render the build script I've been using to make the Slackware binary package as a standalone script that can be used without hunting up the latest Dropline build engine or Slackware's pkgtool sometime later this weekend and donate it back to LL. I'm going to have to code up the part of pkgtool that takes symlinks out of the tarball and puts them into the post-installation script, but beyond that it shouldn't be too much trouble. Then you guys can actually make Slackware packages without having to have Slackware or the Dropline build scripts handy. (My thinking is that it looks like the binary should be compatible with Slackware 9 all the way through to 10.2, possibly excluding -current because it's a "moving target" and I don't use it.)

I don't think you're really going to get around including the provided libs. I've heard someone mention how some of the libs can be built without support for things that SL needs. As well, I have the latest nVidia drivers and SL (through SDL) crashes when not using the provided libGLU.so.. and I do not want to have to downgrade or play around with my drivers like that for a single program.