Re: slashpackage

[prj@xxxxxxxxxxx (Paul Jarc)]

Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx> wrote:
> There is the problem of either having to modify a lot of application
> to look in various directories (e.g. Gnome and KDE the worst
> examples),

This is usually not too hard.  Most packages let you specify an
installation prefix and arbitrary CPPFLAGS/LDFLAGS.  That's usually
enough to put the package in the right place, and looking in the right
places for its dependencies.

> make excessiv use of variant symlinks

Well, that depends on your definition of "excessive".  Given the
benefits, I certainly don't mind the large number of symlinks at all.

> or loose a big part of the flexibility by installing parts in a
> common location.

That mostly crops up with modules for interpreted languages.  E.g.,
Perl really wants to install modules in its own prefix, and look for
them there.

> It is my believe that most applications in a system will be installed in
> only _one_ version. The most important examples are development tools
> and language environments e.g. interpreter. The situation is different
> for libraries, where the availibility of multiple incompatible versions
> will be the _normal_ situation.

I wouldn't go so far as to say that multiple versions would be normal,
but it certainly does happen.  ATM, though, my situation is reversed
from the way you describe.  The only multiple-version packages I have
installed right now are:
- flex; some packages will only build with 2.5.4a; others only with
  2.5.31.
- gcc; the Linux kernel still recommands 2.95.3, according to
  Documentation/Changes, but I use 3.3* for most everything else.
- Guile; I use 1.6.4, but some people still use 1.4*, so I want to try
  to make sure my Guile code works with older versions too.
- Linux; I always keep the previous kernel around just in case.

> Consider a application linked against libpng-1.0 which uses a
> library which is compiled against libpng-1.2 or vice versa.

Just create a new installation of the library, linked with libpng-1.0,
and build the application with that.  autotrace links to libpng and
ImageMagick, and ImageMagick also links to libpng.  We can assume that
autotrace works for the autotrace author - i.e., the author found some
combination of libpng version and ImageMagick version that can work
together.  I may have other versions installed on my system, but I can
also install autotrace's preferred version of libpng, and then I can
install autotrace's preferred version of ImageMagick, linking it with
the newly-installed libpng, and then I can install autotrace, linking
it with the newly-installed libpng and ImageMagick.  This can all be
done without disturbing the other versions of libpng and ImageMagick
(and their dependents) already installed, using the symlink mechanism
described in my last message.


paul