Subject: Re: inflation of PKGREVISION bumps [was Re: CVS commit: pkgsrc]
To: Rene Hexel <r.hexel@griffith.edu.au>
From: Thomas Klausner <wiz@NetBSD.org>
List: tech-pkg
Date: 01/04/2004 16:01:27
On Sun, Jan 04, 2004 at 10:32:50PM +1000, Rene Hexel wrote:
>   This has several advantages:
> 
>   - it separates dependencies from ABI incompatibilities
> 
>   - binary packages no longer will accidentally install against
>     incompatible prerequisites (without requiring PKGREVISION
>     bump orgies)
> 
>   - updating a base package such as tiff no longer forces
>     everyone to recompile everything that depends on that
>     package

I think that's a good scheme.

>   If somebody has gripes with the fact that there now may
> suddenly be two xpaint-2.7.0 binary packages built against
> different versions of tiff (and that there should really
> be an xpaint-2.7.0nb1 package), this is not a problem:
> We can still bump PKGREVISIONs to indicate that the two
> xpaint versions were built against different versions of
> tiff if we want to.

However, it doesn't solve the PKGREVISION bumps, as you
describe here.

>   What's killing us at the moment are not so much the
> PKGREVISION bumps, but the corresponding dependency
> updates that require rebuilding every package and their
> mom.  (And setting these dependencies only solves half
> the problem anyway: while xpaint-2.7.0nb1 will correctly
> work only against tiff>=3.6.1, an old xpaint-2.7.0 binary
> package would happily install against tiff-3.6.1, even
> though it was built against an incompatible
> tiff-3.5.4.)
> 
>   This could be fixed with the above INCOMPATIBLE
> pattern.

So if I understand you correctly, the improvement is
that you could still build new packages with the old
libraries installed; so it's easier to _not_ update your
system just because a new libtiff was imported, and you
only want to install foo-1.0, which depends on tiff.

 Thomas