Re: slashpackage

[prj@xxxxxxxxxxx (Paul Jarc)]

Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx> wrote:
> On Tue, Oct 14, 2003 at 12:55:32PM -0400, Paul Jarc wrote:
>> 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.

That can be done using symlinks.

A slashpackage package contains source in .../src/, and build scripts
and metadata in .../package/.  It creates files in .../compile/ during
compilation, and puts its installed files in .../command/,
. ../include/, .../library/, etc.  So if we have one copy of a package
in /package/admin/foo-1.2.3, then we can create
/package/admin/foo-1.2.3-blah, containing symlinks for src/ and
package/ pointing to the subdirectories of the first copy.  Then if we
run package/compile in the second copy, it will use the original
sources, but any compilation-created files will be separate.  Have a
look at any of my packages at <URL:http://multivac.cwru.edu./> to see
this in action.  (See the package/elsewhere script.)

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

But that's exactly what an absolute path is.  Note that the absolute
path can still contain ABI information if you like.

> Since slashpackage doesn't have a fixed set of library locations, a
> default hint should be added to the binary.

Search paths with relative basenames simply won't work in the most
general case.  Suppose package A provides libfoo.so and libbar.so, and
suppose package B also provides a different libfoo.so and libbar.so
(same name, but unrelated functionality, with no interdependencies
among any of the libraries), and suppose package C wants to link to
A's libfoo.so and B's libbar.so.  If you put A first in the search
path, you'll get the wrong libbar.so.  If you put B first, you'll get
the wrong libfoo.so.  The only way to get it right is to specify an
absolute path for the libraries.

The absolute paths compiled into C's binaries can be under C's own
directory, e.g.: /package/admin/C-1.2.3/conf/A/library/libfoo.so.
(Or, if you prefer,
/package/admin/C-1.2.3/conf/A/library/libfoo-ABI3.so, or some such.)
. ../conf/A would be a symlink to the version of A that was used to
build C.  That symlink can be updated later to point to a newer
version of A, as long as it's the same ABI.

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

Hm?  I don't understand.


paul