[Bug 2048529] Re: Is do-release-upgrade too aggressively removing transitionals?

Wed Jan 10 08:28:51 UTC 2024

FYI: Updated the description and bug states as it is now a question
mostly to the intention/design of ubuntu-release-upgrader.

** Description changed:

+ It seems do-release-upgrade on long term multiple upgrades might
+ unintentionally remove things a bit too aggressive if they have changed
+ to be transitionals.
+ 
+ 
+ Example Scenario:
+ - LTS = src:foo v1 creates package bin:bar v1
+ - LTS+1 = src:foo v2 creates transitional:bar v2 depending on bin:newbar v2
+ - LTS+2 = src:foo v3 no more creates the transitional:bar
+ 
+ Expectation:
+ - LTS -> LTS+1 switches to transitional:bar v2 which pulls in bin:newbar
+ - LTS+1 -> LTS+2 keeps transitional:bar v2 around pulling in bin:newbar still
+ - apt dist-upgrade (even with apt autoremove) behaves this way
+ 
+ What happens:
+ - LTS -> LTS+1 switches to transitional:bar v2 which pulls in bin:newbar v2
+ - LTS+1 -> LTS+2 suggests to remove transitional:bar v2 in the section "Remove (was auto installed)"
+ - If "y" is given, then the former functionality stops working
+ 
+ To be fair, all of this is behind a question, with a default not to do so, like:
+ ```
+ 39 packages are going to be removed.
+ ...
+  Continue [yN]
+ ```
+ 
+ Question to update-release-manager:
+ - Is this intentionally more aggressive than dist-upgrade + autoremove?
+ - If so, what should packages or admins do to avoid that (other than saying "n" at the "Remove (was auto installed)" question?
+ 
+ 
+ ----------
+ 
+ ###
+ 
+ This was initially reported and checked for libvirt (below) but should
+ be a generic behavior
+ 
+ ###
+ 
  # History

  In debian/1.2.10-1 7ca6a8a libvirt-bin was changed to be a transitional.

  This will need to be retained until an LTS change happens so for Ubuntu this was kept and up until Xenial libvirt-bin was a package with content.
  Then it followed Debian

  Later in yakkety yak and later it got changed to be a transitional in 1.3.1-2
  Since we'd need to wait for an Ubuntu LTS 1.3.3-2ubuntu1 kept libvirt-bin (the transitional) around this stayed another while.

  Then post Bionic we dropped even that and libvirt-bin was no more (no
  package, no transitional, no nothing).

  # Problem

  This is kind of how transitions work, but now we've got a report that if
  people installed e.g. on Xenial and just `apt install libvirt-bin` to
  get virsh and other things back then. And upgrade through to e.g. focal
  or even later - they got the replacement packages like `libvirt-clients`
  removed (presumably as nothing depended on it anymore).

  TODO:

  This history is a bit convoluted as the timing was so different due to waiting until after LTSes.
  But we need to:
  1. Install xenial, install libvirt-bin, do-release-upgrade through to Jammy, check if libvirt-clients is still around or not.
  2. if not, then this is a bug and we need to find how to avoid.

  Potentially this is needed in all >Bionic and need to retain the
  libvirt-bin transitional forever? This feels so worng, with a deeper
  look I hope we can find what is actually going on and find a better
  solution.

  P.S. original reporter is Mmike on #ubuntu-server in IRC

** Changed in: ubuntu-release-upgrader (Ubuntu)
       Status: Incomplete => New

-- 
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/2048529

Title:
  Is do-release-upgrade too aggressively removing transitionals?

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

Bug description:
  It seems do-release-upgrade on long term multiple upgrades might
  unintentionally remove things a bit too aggressive if they have
  changed to be transitionals.

  Example Scenario:
  - LTS = src:foo v1 creates package bin:bar v1
  - LTS+1 = src:foo v2 creates transitional:bar v2 depending on bin:newbar v2
  - LTS+2 = src:foo v3 no more creates the transitional:bar

  Expectation:
  - LTS -> LTS+1 switches to transitional:bar v2 which pulls in bin:newbar
  - LTS+1 -> LTS+2 keeps transitional:bar v2 around pulling in bin:newbar still
  - apt dist-upgrade (even with apt autoremove) behaves this way

  What happens:
  - LTS -> LTS+1 switches to transitional:bar v2 which pulls in bin:newbar v2
  - LTS+1 -> LTS+2 suggests to remove transitional:bar v2 in the section "Remove (was auto installed)"
  - If "y" is given, then the former functionality stops working

  To be fair, all of this is behind a question, with a default not to do so, like:
  ```
  39 packages are going to be removed.
  ...
   Continue [yN]
  ```

  Question to update-release-manager:
  - Is this intentionally more aggressive than dist-upgrade + autoremove?
  - If so, what should packages or admins do to avoid that (other than saying "n" at the "Remove (was auto installed)" question?

  ----------

  ###

  This was initially reported and checked for libvirt (below) but should
  be a generic behavior

  ###

  # History

  In debian/1.2.10-1 7ca6a8a libvirt-bin was changed to be a
  transitional.