Imagine a package shipping config file with contents "foo: true; bar: false". You might put the md5 of that in the ucf history, so that packaging that later changes to "foo: true; bar: true" knows that if the user has anything other than "foo: true; bar: false" then it is a customisation that should be preserved.
However, if packaging has iterated between all four possibilities, then list of all possible hashes defeats the purpose. Packaging will believe that whatever the user changed, it isn't a customisation because it was shipped previously by the packaging. Customisations will therefore get lost, contrary to our intention. Therefore, it follows that the list of hashes shipped should be minimally what packaging did actually previously ship; anything more unnecessarily increases the risk of a collision with a user customisation. Since we don't support upgrade leaps beyond LTS-to-LTS, historical hashes can therefore be dropped to keep this minimal. For this SRU, I'd therefore expect to see being added only the hashes involved in the specific issue being fixed - presumably only one - rather than 117. Usually the above never comes up, but I think it's relevant when there are 117, rather than the one or two entries that are common. Similarly, for Hirsute, I'd have expected only the hashes since Focal and onwards to be included. I did ask on IRC how to reproduce the hashes, and Balint pointed out that an explanation exists in README.source. Sorry I didn't see this before - the explanation is in Hirsute but not in this SRU upload. I think this reference to that from this bug comment is sufficient for reproducibility. Perhaps I'm completely wrong here, in which case I'd appreciate a correction. Otherwise, please adjust the upload to minimally fix the specific issue here by only including the required hashes. I also suggest rethinking the Hirsute upload. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1915547 Title: Users are prompted by ucf on upgrade from Trusty to Xenial Status in unattended-upgrades package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: Triaged Bug description: [Impact] During an upgrade from trusty to xenial, users will be prompted to make a decision regarding the diff on unattended-upgrades. This is not a good user experience, specially because the user can make an uninformed decision of keeping the old config file, which will make unattended-upgrades to not work as we expect. [Test case] To reproduce the issue, you can: 1. Launch a trusty vm 2. Perform a do-release-upgrade and observe that you will be prompted with the 50unattended-upgrades change To verify that the error is fixed: 1. Launch a trusty vm 2. Import this ppa into the system: https://launchpad.net/~lamoura/+archive/ubuntu/unattended-upgrades-ppa 3. Configure do-release-upgrade to allow using third parties during upgrade 4. Run a do-release-upgrade 5. Verify the prompt is no longer there and that we end up with the expected 50unattended-upgrades config file [Where problems could occur] The changes in this package should only surface during an upgrade operation. With this change, we are now delivering a new file to the system and configuring postinst to use it. Because of that, we believe this is the only scenario that could be affected in case of a regression is discovered in the package. [Discussion] When upgrading from trusty to xenial, we are prompted about config changes on 50unattended-upgrades with the following diff: --- /etc/apt/apt.conf.d/50unattended-upgrades root.root 0644 2017-05-08 19:21:39 +++ /etc/apt/apt.conf.d/50unattended-upgrades.ucftmp root.root 0644 2020-02-17 18:03:38 @@ -1,11 +1,13 @@ // Automatically upgrade packages from these (origin:archive) pairs Unattended-Upgrade::Allowed-Origins { + "${distro_id}:${distro_codename}"; "${distro_id}:${distro_codename}-security"; // Extended Security Maintenance; doesn't necessarily exist for // every release and this system may not have it installed, but if // available, the policy for updates is such that unattended-upgrades // should also install from here by default. - "${distro_id}ESM:${distro_codename}"; + "${distro_id}ESMApps:${distro_codename}-apps-security"; + "${distro_id}ESM:${distro_codename}-infra-security"; // "${distro_id}:${distro_codename}-updates"; // "${distro_id}:${distro_codename}-proposed"; // "${distro_id}:${distro_codename}-backports"; The reason we are presented with this diff is that the xenial package does not contain a md5sum history file that informs ucf about all the supported configs for 50unattended-upgrades. To fix that upgrade problem, we are prosing the following changes on the xenial package of unattended-upgrades: - Add 50unattended-upgrades.md5sum file into the xenial package - Add md5sum of the current xenial 50unattende-upgrades file into the md5sum history file - Modify ucf command in postinst to be aware of the md5sum history file See the changelog entry below for a full list of changes and bugs. We have performed a manual test with a modified version of the xenial package: https://launchpad.net/~lamoura/+archive/ubuntu/unattended-upgrades-ppa Using that package, we were able to verify that the config change prompt no longer happens from trusty to xenial. Since we are modifying are features on unattended-upgrades, just adding a new file to package, we don't believe there is any regression potential == Changelog == * data: add md5sum history file on the data folder - This file contains md5sum of several supported 50unattended-upgrades config files * data: add xenial md5sum of 50unattented-upgrades into md5sum file * debian/postint: make ucf command reference the md5sum history file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1915547/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
