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).
Then the other packages expressly depend upon the libpng2-so package.
No other libpng.so package would conflict with that, so you could have
several of them all installed at once (they're just one file with a
unique name after all ... if you install a nb++ version, or other minor
version increment, then that would replace the file, but nothing need
notice that particular change, such a minor change would be for 100%
compatible updates).

Then we have a way to express the difference between "this binary package
depends upon this particular libxxx.so.N" and "this source package needs
the headers, objects, etc, for libxxx version M installed".

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

That's fine.  Maybe a bit pedantic, but we can cope with that.

I could cope with upgrading a library if a new package I'm installing
says it needs a newer version, even if that does turn out to be
unnecessary had the builder of the new package known that an older
version of the library would have worked.   What is horrible is when
doing that deletes the old library that everything else I have installed
is using, when there's no need for that at all - the old .so file can
sit there along with the new one.  Deleting the old one means I have
to rebuild everything that used it, that's absurd.

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

We need to handle both people who build from source, and people who
build or install binary packages (or both).  And people who mix strategies
of course.

At the minute, about the only way to cope with using pkgsrc (from src) is
to fetch it once, hope it is all consistent, and then use that one
pkgsrc (tarball probably) to install everything that you need - and never
plan on upgrading anything - instead delete the world and start again
if any non-trivial package is ever changed.

If you don't do it that way you end up recompiling applications multiple
times while upgrading the various things upon which they depend.

The only reason that we should ever need to recompile an application that
is installed and working is if we want to upgrade that application itself.
Or perhaps if something upon which it depends has some fatal problem that
requires it to be removed (rather than just upgraded ... eg: if a serious
security flaw was discovered in some library, requiring all apps that use
it to be recompiled).  Source users of pkgsrc shouldn't need to be spending
their lives recompiling huge applications because of the combination of
more work being done on underlying libraries (which the app clearly doesn't
need, as it is working), and the import of some other application which
does use (for good or other reason) the upgraded library.

kre