pkgin, version numbers and upgrade policy

[Havard Eidnes <he%NetBSD.org@localhost>]

Hi,

I've noticed that we have a more or less common routine that when
significant changes are made to a package, so-called "recursive
PKGREVISION bumps" are done.  If I understand correctly, this is
primarily done so that users of binary packages will notice that
there's a need to also update dependent packages, and to trigger
an upgrade, typically via pkgin.

This upgrade policy (only upgrade packages with changed version
numbers) is different from the policy you get if you do "make
update" on a pkgsrc package which many other packages depend on:
in the latter case, all the dependent packages will be re-built
and re-installed even if their version numbers have not changed.

However, it's evident that we are not entirely consistent in
doing these recursive pkgrevision bumps, as evidenced by the
issue I recently had when upgrading a pkgsrc installation with
libreoffice installed using binary packages and "pkgin", moving
to the latest branch: we had "missed" doing a recursive revision
bump when boost library package was upgraded most recently,
causing some of the intermediate packages which libreoffice
depended on and which used boost to still try to find the old
version of the boost shared library, which in turn caused
libreoffice to fail to start properly.

I'm also seeing another scenario where this upgrade strategy
would break.  Note that the dates are not the actual ones --
these are picked to sketch up a theoretical scenario:

2016-06-28   security/gnupg is at version 1.4.20
2016-07-01   pkgsrc 2016Q2 branch is cut
2016-07-15   recursive PKGREVISION bump for security/openssl ABI bump
2016-08-01   security/gnupg is updated to version 1.4.21

If we then pull up the gnupg update to 2016Q2 (e.g. to close some
security vulnerabilities), and *not* pull up the security/openssl
update (and associated PKGREVISION bump), when the 2016Q3 branch
is cut, there will be no associated PKGREVISION bump of gnupg,
and pkgin will not upgrade gnupg when security/openssl is brought
in with the updated version, possibly causing gnupg to fail.

On the other hand, if security/openssl *is* pulled up after
gnupg, and the associated PKGREVISION bump is done, you will, if
you don't do anything else, end up with the version number for
gnupg decreasing when 2016Q3 is cut, and pkgin will as a result
be unhappy ("no repository for gnupg-1.4.21nb1") when you try to
upgrade.

I'm wondering if the pkgin strategy of only upgrading packages
where the version number changes is sufficiently safe, and
whether it rather ought to use the dependency graph and re-
install all packages which depend on updated packages under the
"full upgrade" option, i.e. behave more similar to "make update"
when building from source.

Comments?

- Håvard