Havard Eidnes <he%NetBSD.org@localhost> writes:
> 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 think you are right about this.
> 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.
Arguably more is needed when switching branches. pkgin should probably
update a package whenever the package's build date or other unique id is
different from the version in the repository.
Attachment:
signature.asc
Description: PGP signature