On Tue, 28 Aug 2001, Robert Elz wrote:

>     Date:        Mon, 27 Aug 2001 11:16:25 -0500 (CDT)
>     From:        Frederick Bruckman <fredb@immanent.net>
>     Message-ID:  <Pine.NEB.4.33.0108271039170.28568-100000@tautology.immanent.net>
>
>   | 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",
>
> Yes there is.   As I suggested some time ago, we should have the shared
> libraries separated out as packages of their own.  Nothing else in them
> but the .so file (in the binary packge - and the admin files of course).

I'm still working out the details of my idea of leaving a fake, stub
package with only the *.so* files after upgrading a shared library. I
have no intention of packaging up the shared libraries sans
documentation and headers as a portable package, as that would likely
violate licenses and otherwise offend people. The idea is to allow you
to build packages "correctly" (at least under the current discipline),
without having to delete everything other package on the machine.

Just from doing this "by hand" (code/script incomplete), I've
encountered some problems already:

1) If you upgrade wily-nily, it's possible to link against both a
single version of a shared library directly, and another version or
versions of that same shared library through shared library
depedencies, resulting in a binary for which "ldd" list multiple
versions of the same shared library.

2) The wildcard depends confuse the issue, as they could then match
packages that were built after the package in question, and so don't
truly belong in the list.

I think I can solve "2)" by selectively un-winding the wild-cards in
the previously installed packages. (This would never change "make
package" of a new package.) The solution to "1)" would require some
kind of tool to script upgrades, another idea I'm tinkering with.

I haven't really considered making the "stub" packages portable, so I
don't know what kind of problems that would cause. The obvious one,
the support issue of folks trying to build against headers that don't
match the installed library, is bad enough to make that idea very
unpopular, I'd imagine.

Frederick