Re: pkgin, version numbers and upgrade policy

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

> On Mon, Aug 29, 2016 at 11:16:25AM +0200, Havard Eidnes wrote:
>> 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.
>
> The point mostly is that we want to have different names for binary
> packages that have different contents.
>
> The most common cause for recursive bumps is libraries changing their
> major version number.
>
> To stay with your openssl example, if it the openssl update bumped the
> libssl version from 10 to 11 and you don't bump gnupg's PKGREVISION,
> you don't know if the binary package was built against the old openssl
> (and depends on libssl.so.10) or the new one (and depends on
> libssl.so.11).

I think I understand that different binary contents should imply
different version number is necessary.

However, as I tried to illustrate, when you need to revision-bump
isn't always easy to tell.  To further complicate matters, mix in
the stable branches and the process of upgrading from one stable
branch to the next.

> The case with boost you mention was a bug. Bugs happen, but we try to
> fix them when we find out.

Today this appears to be a manual process with no tool assist on
the "detection" side, i.e. to realize when it's necessary to do a
recursive revision bump.  I guess I'm wondering if there is
something we can do to make this process less error-prone.

Regards,

- Håvard