DragonFly kernel List (threaded) for 2003-10
On Tue, Oct 14, 2003 at 12:55:32PM -0400, Paul Jarc wrote:
> Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx> wrote:
> > I know, but say "the source is accessible via /package/..." means
> > someone will write his/her build scripts to *assume* it is there.
> That's how native slashpackage packages are supposed to work. OTOH,
> for "foreign" packages, in my SPF project, I don't put the sources
> under /package at all, except for the Linux kernel, since a few
> packages need those sources.
One reason is to simplify user package building where rw access to
/package is granted. This might a vanish with a proper VFS, not sure
yet. The second reason is package building is greatly simplified when
no subpackages are involved. This too might be void if there is a
common rule how to name the src subdir. It is should be possible
to separate source and build location too, esp. if we are going to
support more then one CPU target or dependency set.
> > The same for referencing files from other packages. All references
> > at *build* time should be redirectable to at least another location.
> What's wrong with setting up the symlinks before building? Why do you
> want to use another method of indirection instead of the one symlinks
> already provide?
To provide a clean way to recompile a package to match newer dependencies
(like the libpng case) without affecting the installed packages. You
agree that the installed package set should only modified if all packages
to be updated are successfully build, do you?
> > I don't want to say "link to this absolute path", just link to that
> > library and here is where to find it.
> What's the difference?
The SONAME of a library specifies it's ABI compatibility. A program
says "I need a library with this ABI". That is enough with a fixed set
of library locations (e.g. /usr/lib,/usr/local/lib). It should be
possible to give a hint to the dynamic linker to provide an alternative
location for a specific library. Since slashpackage doesn't have a
fixed set of library locations, a default hint should be added to
the binary. Yes, the SONAME could an absolute path, but an override
statement e.g. for the update process would look like
/package/base/libc/libc.so => /build/base/libc-new/libc.so and so on,
which is IMO wrong since it shadows the original intend (ABI!).