On Fri, 8 Sep 2000, Johnny C. Lam wrote:

> > 	We have two dependencies - the existing build dependencies, and
> > 	the 'binary' set.
> > 	eg: build may be lib>=1.1, and if you build against 1.1 then
> > 	then binary dependencies are lib>=1.1. But if you build against
> > 	1.2 then binary dependencies should be lib>=1.2
> 
> Well, when the gettext package was reworked to build a shared library,
> all dependent packages had to upgrade their dependency on gettext to
> at least the version with the shared library.

Not an issue for the old packages which depend on gettext, since they
were all built against a static gettext.

> And when freetype-lib
> was updated to a version with a new major number on the shared lib,
> all dependent packages were reworked to build with and depend on at
> least the version with the new major number.

Also not an issue. The new packages probably wouldn't even build
against the old freetype-lib. And since you reworked them anyway, why
not bump the version number of the dependencies?

> We could extend this to every time a package with a shared library
> gets updated, then all dependent packages need to be changed to depend
> on at least the updated package.  This would solve the problems form
> binary package users, but would be a slight pain to package builders
> who need to constantly chase new versions of packages.

Such would tend to defeat the purpose of '>=' wildcards. For instance:
ethereal is known to build and run against glib-1.2.7, and it builds
and runs against glib-1.2.8. Hence the wildcard, glib>=1.2.7. This
serves pkgsrc users, and it serves binary package users who upgrade
fastidiously. (Assumming that the binary packages were posted with the
same care.) It only hurts people who upgrade carelessly, or who are
"victims" of casual package posters (guilty as charged).

As far as that goes, I like David's idea of fixing the @pkgdep's in
the binary packages.