Subject: inflation of PKGREVISION bumps [was Re: CVS commit: pkgsrc]
To: Jeremy C. Reed <reed@reedmedia.net>
From: Rene Hexel <r.hexel@griffith.edu.au>
List: tech-pkg
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 
> utilities)
> work fine for packages built using this newest tiff. I guess we could 
> just
> 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

INCOMPATIBLE_WITH=		tiff<3.6.1

   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
being updated.

> 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?

   Cheers
       ,
    Rene