Public bug reported: We have observed recently some packages make incompatible changes in new versions, shipped in new ubuntu releases, or some other similar scenario where an existing configuration for some reason doesn't work in a new ubuntu release, and the package itself did not, or cannot, take care of it itself.
Recent examples include: - dovecot: big configuration changes: https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/2150663/comments/4 - mysql: config option no longer valid in the latest release: https://bugs.launchpad.net/ubuntu/+source/mysql-8.4/+bug/2150824/comments/2 - libpam_mount: not a configuration change, but a particular configuration which can prevent the release upgrade from finishing: https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/2130575 - rabbitmq-server: needs a specific upgrade procedure due to feature flags: https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/2074309. This package actually has a quirk/hook in place already in the release upgrader. Sometimes the package can take care of such changes (either by coping, or perhaps by changing its config file on-the-fly (less common)). Sometimes we rely on just release notes. It sounds like we could do something in the release upgrader about it. I don't know if it would fit as an existing quirk/hook, or if we would want a new class of such checks. But with these, we could: - have per-package specific release upgrade checks. For example, in the mysql case, we could detect that mysql is installed, then run this check which would look through the mysql configuration trying to detect if the config option that no longer exists in resolute is being used. - these checks would then halt the upgrade, tell the user about the problem, perhaps also link to the specific release notes entry about it, and give the option to either continue with the release upgrade, or abort it to give a chance for the user to adjust. - similarly for the pam_mount case, we could warn the user that having "user=*" in the pam_mount config could make scripts that run "su" in postinst halt, prompting for a password - for the dovecot case, there are too many configuration changes, so we would simply halt the upgrade, link to the upstream page detailing the changes, and then allow the user to either stop, or continue. Again, in some cases we would rather fix the actual bug in the actual package, but sometimes that is not feasable, and the user must take some action. This feature would prevent the release upgrade from being interrupted in the middle, which is always very annoying to recover from (if you are an expert), and very difficult (if you are an inexperienced ubuntu user). So, in a summary, this bug here is about dealing with these scenarios. It can be with a new class of hooks in release-upgrade, and/or just adding the specific ones I mentioned using the existing infrastructure, like rabbitmq-server is doing already. But perhaps we can benefit from a bit of generalization here, as I see a pattern: - check for the scenario that will break the release upgrade - issue advisory text - link to bug and/or release notes about this - option to continue or not ** Affects: ubuntu-release-upgrader (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2151222 Title: Add pre-upgrade checks for package specific conditions To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2151222/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
