Understanding the Nature of Problems Caused by Third-Party/PPA Repositories During Ubuntu Release Upgrades

I currently have Ubuntu 20.04 installed and wish to upgrade my release to 22.04. I also have several third-party repositories enabled and some set of packages installed from each. I understand from much research that this situation tends to be a major cause of release upgrade failures and has driven many to recommend doing a fresh install of Ubuntu every time a release upgrade is desired. Frankly, this is not a practical solution for me because it requires a major effort every couple years to rebuild my system to what it was (e.g. installing software, downloading data that needed to be backed up during the fresh install, etc). Instead, I would like to understand the nature of the problem and learn how to deal with it head-on such that I can use the standard Ubuntu release upgrade path (e.g. update-manager or do-release-upgrade).

I am aware that the release upgrade process currently disables all third-party/PPA repositories. How exactly is this done (e.g. does it basically just comment out those lines in /etc/apt/sources.list and the .list files in /etc/apt/sources.list.d/)? Please also provide a detailed explanation as to why this is done and what one is expected to do post-upgrade (hopefully with examples?).

I am also aware that recently the release upgrade process has a new option to allow for keeping third-party/PPA repositories enabled. What exactly is this doing differently and what is one expected to do post-upgrade in this scenario?

I recognize that this question may be difficult to answer completely due to the ill-defined nature of third-party software. What I'm basically seeking is the understanding necessary to make informed decisions as to what I should do through this process.

For reference, the following is a list of the third-party repositories that I have on my system. Each is found in its own .lists file in /etc/apt/sources.list.d. Perhaps these can be used in any examples.

deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu   focal stable
deb [arch=amd64] https://dl.google.com/linux/chrome/deb/ stable main
deb [arch=amd64] https://keepersecurity.com/desktop_electron/Linux/repo/deb stable main
deb [arch=amd64 signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu focal main
deb [arch=amd64,arm64,armhf] http://packages.microsoft.com/repos/code stable main

Lastly, I have read this question and it is not particularly helpful. I suppose I'm mostly focused on understanding what exactly the Ubuntu release upgrade process will do and the details of how/why third-party repositories cause problems so I have the knowledge to make decisions when I'm evaluating a particular repository.

"*How exactly is this done (e.g. does it basically just comment out those lines in /etc/apt/sources.list and the .list files in /etc/apt/sources.list.d/)? *"

Yes, that's exactly how it's done by the do-release-upgrade Python script.

"I am also aware that recently the release upgrade process has a new option to allow for keeping third-party/PPA repositories enabled."

It's not quite recent (that link is from 2019). The feature is for testing, so PPA authors can discover these little conflicts and errors so they can fix them. It merely prevents the non-Ubuntu (PPA, third party) sources from being disabled. It makes no other changes to the release-upgrade calculations. Using might (or might not) break your upgrade.

"I would like to understand the nature of the problem and learn how to deal with it head-on"

The problem is most commonly version conflicts. Let's offer an example of how it works:

• Your Ubuntu 20.04 includes a (example) package libfoo 1.1. You have several applications that depend upon it.
• During the 20.04 cycle, you installed the Frobozz PPA that provides --among other packages-- libfoo 1.3.
• Finally, you want to release-upgrade to Ubuntu 22.04, which includes libfoo 1.2.

During the release-upgrade, unbeknownst to you, updated package baz now specifies that it needs exactly libfoo 1.2, usually not a problem since the entire release is built assuming that version. However, since libfoo 1.3 is already installed, the baz install fails along with all packages that have baz as a dependency.

The "head-on" solution is to uninstall the conflicting 20.04 packages from the Frobozz PPA (including libfoo 1.3) and return your system to stock Ubuntu (libfoo 1.2). Then you can install compatible 22.04 packages when the PPA author gets round to building them. Or you can install 22.04-compatible packages from elsewhere. Recall that uninstalling an application package does NOT delete any of the data in your /home directory.

• Building the release around a single, uniform set of dependency versions has been a fundamental element of Debian system design for over 25 years. Don't fight it. They are not going to change it, so go with the flow.