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