Subject: Re: (Incomplete) List of pkgsrc Improvements
To: Dieter Baron <>
From: Marc Espie <>
List: tech-pkg
Date: 08/02/2007 11:58:19
On Tue, Jul 31, 2007 at 12:17:46PM +0200, Dieter Baron wrote:
> 1.4 fix open-ended dependencies
>   GOAL: Currently¸ dependencies are open-ended in that any version
> greater than the required minimum version is accepted.  However,
> future versions might not be compatible with the version a package was
> built against -- the most common cause is a shared library major
> version bump.  Thus, we need a way to express that those newer
> packages do not satisfy the dependency.  As we do not know which future
> versions will be incompatible, we cannot encode that in the dependency
> pattern of the ``parent'' package.
>   Joerg suggested an elegant way to solve this: in each package, note
> the lowest version a package is compatible with; when a shared library
> major number is bumped, this is set to the current version.  When
> checking wether a package satisfies a dependency, when its lowest
> compatible version is higher than the version requested by the
> ``parent'' package, it is rejected.
>   Another way would be to use the PROVIDES and REQUIRED lines from
> +BUILD_INFO (which record information about shared libraries included
> or used by the package).  However, that is more complicated and does
> not handle incompatibilities for reasons other than shared library
> major version bumps (like e.g. command line incompatibilities of an
> included utility).
>   RATIONALE: We need a way to catch mismatches early, so we don't
> install an inconsistent set of packages.  This also helps in-place
> replacement of package (without deleting all the packages that depend
> on it), as we can check beforehand wether all depending packages are
> compatible with the new version.

This is a nice idea. In OpenBSD, we currently have the equivalent
of PROVIDES/REQUIRED, and it is indeed complicated. Adding an annotation
that says `not compatible before XXX' is very nice.

However, I'd say it might still be a good idea to have both.

The reason is that many, many packages are only used as dependencies for
their libraries, and there is no problem with keeping the old libraries
around for a while. Thus, you can have a scheme where you can update 
some packages even when they're needed by something: you just have to keep 
the shared libraries around in a stub package (we name these .libs-*)
It works surprisingly well in most cases.