[plug] Easy Installation: Linux Desktop Market

[Cameron Patrick]

Daniel J. Axtens wrote:

> For example, say I'm packaging neuronstorm (neuronstorm.sf.net). It's
> got files that should go to /usr/bin, /usr/share/neuronstorm/,
> man1/neuronstorm.1, info somewhere, and /usr/share/doc/neuronstorm.
> That's (hopefully) the same everywhere, and, for distros that require
> things in different places, ther relevent control files could be set
> up differently.
> 
> So, if I'm installing on Debian, it would just pull out the
> debian/control, put the archive together, and send it off to dpkg.
> Mdk/FC/RH - pull out the spec file, put the archive together, send it
> to RPM, etc.

For packages that simple, you could probably get away with using alien
to convert from .deb to the package format of the week - assuming that
the libraries are binary compatible.  Mostly they will be, kinda.
However, some examples off the top of my head:

 - Debian Sarge shipped with a glibc 2.3.2 which includes some patches
   from glibc 2.3.4; as a result a sarge system will run binaries
   compiled on other distros' glibc <= 2.3.2 but binaries compiled on
   sarge are likely to require glibc >= 2.3.4.

 - Ubuntu Hoary was released a month or so before sarge and included
   an older glibc (2.3.2 without the patches) but newer GTK and GNOME
   library stack.  As a result, GTK apps compiled on hoary won't run
   on sarge, and vice versa.

 - The C++ ABI changed with gcc 3.2 and so compiled with gcc 3.2 will
   not run on machines with prior gcc versions.  It happened again
   with gcc 4.0.

 - There are approximately umpteen different ABIs for libpng.  Most
   distros will allow you to have several of them installed at once
   so that apps requiring different libpng versions can be
   simultaneously installed.  However, if a programme depends on two
   different libraries which have been compiled against different
   libpngs, all hell can break loose when you least expect it.

(Note that the above are worst-case rules, and some apps won't use the
incompatible parts of the libraries.)

Worse than this, glibc hasn't supported static linking for non-trivial
applications for quite a while, so saying "here's a nice statically
linked binary bundle" won't work either - besides the incredible waste
involved in duplicating libraries already present on the system.

I'm not sure what the solution to all this is (and I'm about to eat
dinner), but I can't see an obvious easy one.

Cameron.