On Mon, 27 Aug 2001, Robert Elz wrote:

>     Date:        Mon, 27 Aug 2001 10:02:57 -0500 (CDT)
>     From:        Frederick Bruckman <fredb@immanent.net>
>     Message-ID:  <Pine.NEB.4.33.0108270933000.28568-100000@tautology.immanent.net>
>
>   | but we
>   | shouldn't allow binary packages with binaries that are linked against
>   | somethething other than "libpng.so.2.1".
>
> Aside from being an occasional user (of ones I make myself) binary
> packages, I know almost nothing about the way they work, but they
> should depend upon the library version actually used to build
> the package (and allow minor version bumps beyond that).

With our present system, a package can only depend on a particular
version of another package (or a closed range of versions, or a
half-closed range). There's currently no way to express, "this package
depends on any png package that contains libpng.so.2.1", as there's no
way for the pkg tools to map the version of the package to that which
it contains.

Moreover, on ELF platforms, shared libraries that depend on other
shared libraries (as "imlib" depends on "png") demand the particular
minor version they were linked against, which ends up causing the
resulting executable to depend on a particular minor version. So if a
package has only executables depending on it, you could do that. Not
so for "png". The best you can do there is to depend on png>=1.0.12,
which is to say, png-1.0.12, as that's the only package that currently
a member of the half-closed range '[1.0.12-)'.

> If the linker
> is working correctly, avoiding serious problems because of this should
> be semi-automatic - though having pgksrc (pkgbin perhaps...) upgrade
> libraries when needed is definitely a feature.

On your first point, the battle is already lost. One your second, you
can't begin to design a tool to do everything you want until the
binary packages contain the right dependencies (or unless you revamp
the dependency system). Otherwise, how would it know you need to
upgrade the shared library?

> The relationship between what is in the Makefile and what the binary
> package gets built to use should not be text equality...

Well it is (for now ???).

>   | And what is a _package_ system, if it can't produce binary packages?
>
> The current one, when it comes to libraries, is very weak.


Frederick