[Bug 2151222] Re: Add pre-upgrade checks for package specific conditions

[Simon Johnsson]

I think this is a great idea! Especially since users are otherwise, as
you say, on their own if an upgrade breaks.

In my opinion, this would probably work best as its own new class of
checks. This way we get a better overview in general about configuration
changes and can share logic between them.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubuntu-release-upgrader in
Ubuntu.
https://bugs.launchpad.net/bugs/2151222

Title:
  Add pre-upgrade checks for package specific conditions

Status in ubuntu-release-upgrader package in Ubuntu:
  New

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2151222/+subscriptions