DragonFly kernel List (threaded) for 2003-10
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: slashpackage
On Fri, Oct 10, 2003 at 01:24:30PM -0400, Paul Jarc wrote:
> Joerg Sonnenberger <joerg@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
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]