slashpackage

[Paul Jarc]

Joerg Sonnenberger <joerg at xxxxxxxxxxxxxxxxx> wrote:
> 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.

Ok.  I haven't really run into any problems there, but that may be
just because I haven't installed Gnome or KDE.

> I don't like Bernstein's idea of mixing source and installed binaries
> in one tree,

Symlinks can fix that, if you like.  The idea is that files should be
*accessible* via their standard /package/... paths; they can be
*stored* however you like.

> neither is /package enough for a _whole_ system.

My whole system uses /package.

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

/package can always be available.
<URL:http://multivac.cwru.edu./fs/#tricks>

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

I see.  The Right Way to handle this is to make sure each package is
properly maintained, so that they can all link to the latest version
of their dependencies.

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

That's already possible.  Make the library's SONAME be its absolute
path.  Or, if you want different programs to refer to the library via
different paths, then for each program, build a dummy library whose
SONAME is the (program-specific) absolute path of the real library you
want to link to.  Then use that dummy library on the gcc command line
for linking.  But I agree that it would be nice if ld had a
command-line option that says "link to this absolute path, ignoring
the SONAME stored in the library".


paul