Subject: inflation of PKGREVISION bumps [was Re: CVS commit: pkgsrc]
To: Jeremy C. Reed <firstname.lastname@example.org>
From: Rene Hexel <email@example.com>
Date: 01/04/2004 13:46:26
On 04/01/2004, at 7:35 AM, Jeremy C. Reed wrote:
> Please see my other email where I mentioned about testing all the 500
> packages to make sure that old version of tiff (libraries and
> work fine for packages built using this newest tiff. I guess we could
> assume they work and fix as they come up. (Please note that I did this
> because I was asked to do this.)
In theory, all dependent packages should be tested anyway
before updating a package. But I concede that in practice this
very often is not done (and in this case it would have doubled
the effort, testing old and new binaries).
I don't know what the solution is. I tend towards the more
pragmatic approach: if I have enough reason to believe that a
package is backwards compatible and I have tested it with a
sufficient/representative number of dependencies, I usually
assume that it will work with other packages as well.
>> versions? More often than not I have found myself recompiling
>> almost my entire installed package base instead of being able
>> to do any real package work in the recent past.
> I agree that there should be a better way.
Okay, what about this: add a new INCOMPATIBLE_WITH (better
names welcome) entry that is stored in binary packages.
This entry lists the version number(s) of the same package
it is incompatible with. E.g., for tiff-3.6.1 we can set
Binary packages compiled against anything before tiff-3.6.1
will then not install against tiff-3.6.1, even though their
dependencies might, for example, be tiff>=3.5.5
This solves the problem for binary packages (assuming that
appropriate, newer versions are being uploaded onto ftp@),
while allowing people who compile their packages from source
to update whenever it suits them, rather then forcing them
into recompilation bonanzas.
> I don't know what "nb" means. Maybe "NetBSD or maybe "nota bene".
IIRC, it was meant to stand for "NetBSD". It was invented
to allow for changed version numbers where there was a
(user-visible) change to the NetBSD package without the distfile
> Anyone volunteering in adding a "new handle to do such things"?
What about the above idea? I haven't read through the package
tools sources yet, but I believe this should be fairly
straightforward to implement.
Thoughts? Comments? Flames?