slashpackage

[Joerg Sonnenberger]

On Fri, Oct 10, 2003 at 01:24:30PM -0400, Paul Jarc wrote:
> 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.

Which don't support slashpackage yet.

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

I know, but say "the source is accessible via /package/..." means
someone will write his/her build scripts to *assume* it is there.
The same for referencing files from other packages. All references
at *build* time should be redirectable to at least another location.

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

OK, that should be possible. Adding /rescue to provide static
recovery tools like FBSD5 has would work.

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

Mainting packages is a different problem ;-) Having a proper way to
deal with such dependencies is a not tidious and having to rebuild
the system is annoying.

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

Not exactly. I don't want to say "link to this absolute path", just
link to that library and here is where to find it. With a Virtual
File System, link against this library and remember its location
would be enough. I want to keep the SONAME for what it is used now,
to identify the ABI of a shared library. It must be possible to
override the locations on a per library base.

Joerg

> paul