Jim Wise (J) and Thomas Klausner (T) wrote:

T> Bump PKGREVISION for previous (hi jwise!).

J> Originally, PKGREVISION was implemented to allow packages which depend 
J> on a package to depend on a change.  This is irrelevant for a leaf 
J> package.
J> Over time, PKGREVISION was extended to cover other major changes, 
J> particularly security and UI changes.
J> To what end are you trying to tell them apart?  This is not a change 
J> which is visible to a package depending on this one.

T> To what end did you make the change? Is it visible to the end user
T> or not?

J> It is visible to a user setting up the package for the first time ...
J> It is invisible to users upgrading -- the users who are served by
J> bumping PKGREVISION for changes which do affect them, and badly disserved
J> by bumping PKGREVISION ... for invisible changes....

T> It changes the binary package. There are binary packages before
T> this change and after this change, and there should be a way to
T> find out which of the two you have without starting the disassembler.

There is: /var/db/pkg/dict-client*/+BUILD_VERSION holds the exact CVS
revisions of the pkgsrc files used to prepare the package.
pkg_info -b dict-client  prints it out.

Remembering that, I wonder if there is some merit to an argument that not
all changes need to entail a PKGREVISION bump ... and some way to reach a
consensus on how to tell the changes that do from the changes that don't.

There are points I like in both these arguments - it is good to unambiguously
know when things have changed - at the same time I sometimes wonder while
rebuilding my package-world for the nth time, whether all of the changes had
to set off automated compatibility alarms that make me do extra work.
Maybe +BUILD_VERSION is just the place to look for those changes that don't
affect dependencies.

-Chap