Since apt-get has changed behavior and refuses to update if the code name
in a Release file has changed from the one it saw before, propellor systems
that are tracking Unstable or Testing need a manual intervention after each
major stable release (apt-get update --allow-releaseinfo-change).
(It seems that when unattended-updates is available, it does automatically accept the change.)
I am seeking advice about what propellor should do about this. Should Apt.update include --allow-releaseinfo-change when the host is following a rolling suite?
Or does doing so defeat whatever presumably good rationalle there is for making this a manual action? Or perhaps there is no really good reason apt does this when following a folling suite?
--Joey
I think that the point of this was to prevent people with 'stable' in their sources.list from accidentally upgrading to a new stable release. Similarly, to prevent users with 'testing' in their sources.list from upgrading to the new testing, when what they wanted to do was track stable+1.
I think that when a user uses propellor's
TestingandUnstabletypes they are explicitly requesting a rolling release, so it seems find to pass it for those suites.This is not based on reading any discussions about the new feature. Just my own inference as to its purpose.
That matches my intuition of it. And propellor's Unstable and Testing are indeed intended to explicitly request a rolling release. (I thought that "unstable" and "testing" were also intended to explicitly request that?)
Anyway, I've made Apt.update add the new argument for Unstable and Testing.