On 06/22/2018 01:14 PM, Freddy Rietdijk wrote:
> Typically we should always permit "patch" level updates, simply from a
> security point of view. "major" upgrades typically break things whereas
> "minor" do so only occasionally.
Except for OpenSMTPD, for which I thought a patch-level update was OK,
but it wasn't (a `sed` performed by the derivation was no longer
changing anything, and the failure was thus silent during build and even
execution, but a configuration parameter was ill-set)
Or for Dovecot, for which the 2.3.0.1 -> 2.3.1 upgrade included a
rewrite of the message parser, that ended up rejecting all incoming mail
from OpenSMTPD (which broke my installation until I noticed that mail
was no longer being delivered)
In an ideal world, all patch-level upgrades would be fully automatable,
but I fear it wouldn't actually work out well. And if such a meta
attribute was added, it would have to have a meaning for *all* packages.
Also, with the dovecot (2.3.0.1) or the OpenSMTPD (6.0.3p1) numbering
schemes, I'm not sure “major”, “minor” and “patch” could fit them well.
And if this was added to nixpkgs (and not to the language-specific
tooling), it would have to handle all possible version numbers IMO.
Maybe have it be a function like this?
meta.permitAutoUpgrade = versionFrom: versionTo: boolIsOk
This would have the bonus of being fully-configurable, and helper
functions could be provided in lib, so that it could be set at
meta.permitAutoUpgrade = lib.permitMajorUpgrades if the package follows
the x.y.z versioning scheme.
Anyway, I must say I believe that at some point there must be human
intervention to check the changelog looks good, etc. for nixpkgs. And
I'm more and more thinking that all these fully-automated bumps should
be moved to language-specific overlays, that could even consist in a
full dump of the language package manager, where reasonably possible.
But on the other hand, I guess that even including only the strict
minimum of packages required for the applications in nixpkgs, there are
still too many packages for reasonable human-done maintenance? If so…
meh. We're doomed anyway, and things will break due to automatic
upgrades, as upstreams aren't always following their own guidelines, so…