do-release-upgrade unecessarily disables PPA's which are not release specific

[Daniel Bull]

The upgrade process from 16.10 to 17.04 (for example) performed by both the GUI and do-release-upgrade CLI methods, disables 3rd party PPAs. Whilst it is understandable that PPAs targeted specifically at the release which is being upgraded should be disabled, it seems unnecessary to disable those which are release independent.

For example these are typical PPAs which are release independent and are currently unnecessarily commented out by the upgrade process (as can be seen they state "stable" rather than "yakkety" on the config line):
deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main
deb http://repository.spotify.com/ stable non-free

Since disabling PPAs puts a users machine at significant risk (because packages installed by those PPAs are left without security updates) it would seem preferable to minimise the number of disabled PPAs wherever possible. Modifying the PPA disabling process to first check the configs release code name matches the release being upgraded from (in this case yakkety) before commenting it out would dramatically reduce this number and improve security considerably.

Whilst its appreciated that the long term solution to this will be snap packages, it seems that the recent trend towards installers automatically adding PPAs has left novice users unaware of what PPAs are, putting them at even greater risk of running unpatched packages. The upgrade process should target a similar skillset level and where possible not require the user to have to deal with PPAs directly - the modification described above would be a step towards that.

(...it would at least improve on the current situation which is (for example) potentially leaving millions of unskilled Linux users running unpatched copies of Google Chrome.)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[James Lewis (james-fsck)]

It seems that in the past it was the case that if one package source failed, then no updates would be executed by the update manager. I'm not certain if this issue has been fixed.

As regards the issue raised above, it does seem that simply disabling sources/PPA's after software is already installed is a dangerous course of action as security issues may arise.... perhaps if the first issue was resolved, an additional step in the upgrade process to allow the user to either re-enable, or purge sources/PPA's could be included. Any sources referencing the old release could be stepped forward, and sources using a generic release ID such as Chrome would need no modification...

Ultimately, it is obviously desirable to give the user a clean upgrade, but perhaps not at the expense of then being exposed to major security risk.

[Daniel Bull (ubuntu-frozenmist)]

Ahh, if one PPA can break the updater then it does make sense to disable them all during the upgrade process. Like you say an additional step to enable them again once the upgrade is complete would be the solution in this case.

[James Lewis (james-fsck)]

The ability of one broken PPA to break the entire process must be addressed, using the command line will ignore a 404 error, but the update manager simply stops at "Failed to download repository information", and will not proceed...