pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkgin, version numbers and upgrade policy

Havard Eidnes <> 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

Home | Main Index | Thread Index | Old Index