David Brownlee <abs@netbsd.org> writes:
> On Wed, 6 Sep 2000, Frederick Bruckman wrote:
> 
> > On Wed, 6 Sep 2000, Hubert Feyrer wrote:
> > 
> > > OK, and what do you suggest then? Tell them that a lib of <newer version>
> > > would be required, judging from information encoded in the (new) "app"
> > > pkg? 
> > 
> > Yes, and also update the DEPENDS in the app pkgsrc (if it isn't fixed
> > already), and delete the app binary package with the broken dependency
> > from the server. [We shouldn't say "app" depends on lib>=1.1 unless
> > "app" built against lib-1.2 is known to work with lib-1.1. I don't
> > want to lay a heavy "burden of proof" on the pkgsrc maintainer though,
> > I just want a way to fix it when someone reports a problem.]
> 
> 	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.  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.

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.

     -- Johnny C. Lam <lamj@stat.cmu.edu>
        Department of Statistics, Carnegie Mellon University
        http://www.stat.cmu.edu/~lamj/