Re: slashpackage

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Thu, Oct 09, 2003 at 03:26:27PM -0400, Paul Jarc wrote:
> 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.

The problem is _not_ installing the e.g. gnomelibs under
/package/<what ever>/gnomelibs-??, the problem is providing
a unique <PREFIX>/share structure e.g. for Gnome. Using
slashpackage would either need one symlink per app per subdirectory
which can be quite a lot. Providing CPPFLAGS and LDFLAGS is
an annoying but mostly mechanical way. We could use something
like buildlink from NetBSD's pkgsrc for that.

Another option would be a virtual merging filesystem. That
would lead to interesting administrative and performance
questions.

> 
> > 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.

I agree that there slashpackage simplifies quite a few things.
I don't like Bernstein's idea of mixing source and installed binaries
in one tree, neither is /package enough for a _whole_ system. But
the later could be solved by installing the _base_ system partly
under /system and /package, the former for the boot process where
/package might be unavailible.

> 
> > 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.

That my point. It is not only Perl, many other application and esp. the
Desktop Environments work that way.

> 
> > 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

Sorry, my fault. I wanted to say that ;-) Think before writing in a
foreign language ;-(

> 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.

I tried to illustrate the problem with a simple example. Seems it
was to simple. The problem arises if you don't want to install a
new version of the library since that could mean _all_ programs
and libraries needs to be recompiled. C++ libs are most annoying in this
regard. Now let us assume the library is a requirement of QT or one of
the Gnome libs. Having to recompile 100+ apps and libs is not
funny. A way to "fix" this without having to installing each and every
lib is a must from an administrative POV.

BTW it could be useful to extend the current rpath-mechanism of the
linker to fully specify the location of each indepent library. 

Joerg

> paul