Prevent Mozilla Debian repo consumers getting stuck on old Firefox versions following distro upgrades that rename the sources.list
Categories
(Release Engineering :: Release Automation, enhancement)
Tracking
(Not tracked)
People
(Reporter: muffinresearch, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
Having recently upgraded Ubuntu to the latest LTS, I noticed that Firefox Nightly .deb updates had stopped. The reason is that 3rd party source lists files get a suffix of .distUpgrade to guard against unknown compatibility issues with the new distro version you’re upgrading to. Whilst the Ubuntu distro upgrade process does mention this is happening (and the need to take action manually), it’s easy defer it and then forget, which is exactly what I did.
Filing this bug to consider if there are any options for improving this so that consumers of the mozilla .deb repos don't get stuck on old versions post-upgrade if they forget to update the relevant source list that was disabled by the distro upgrade.
Comment 1•1 year ago
|
||
Thanks for filing this bug, :muffingresearch! I looked into it.
First of all, I do reproduce the same behavior. I confirm that after the .distUpgrade is applied, apt ignores it. I want to acknowledge that it's a known behavior in Ubuntu (and likely any Ubuntu-based distribution). That's a recurring question no matter the 3rd party APT repo or the PPA people installed on their machine.
With that said, I checked what Chrome and Chromium do. They actually documented that behavior in their FAQ[1]:
Q. Why does the Google Chrome package install a cron job on Debian systems? (i.e. Debian, Ubuntu)
A. We found some Debian-based distros will remove the Google Chrome source when doing an upgrade, meaning users will silently stop getting updates. All the cron job does is verify the above sources line still exists; it doesn't do any updating itself. Again, /etc/default/google-chrome controls this behavior. You can either create an empty /etc/default/google-chrome or explicitly add the line: repo_reenable_on_distupgrade=false.
The cron script in question is this one[2]. It calls that shell function[3] which basically rewrites the missing file in source.list.d/. They also tell Users just before their first download that they do have the ability to deactivate this feature[4]:
Note: Installing Google Chrome will add the Google repository so that your system will automatically keep Google Chrome up to date. If you don’t want Google's repository, do 'sudo touch/etc/default/google-chrome' before installing the package.
More precisely, they can define the variable repo_reenable_on_distupgrade to false[5].
I think we should do something similar. We could add to the shell script (bug 1926556). However, we'll likely need to be able to make changes in case the we need to fix this update mechanism. That makes me wonder whether the shell is the best approach. Maybe we should bake this in the deb package itself just like Chrome does.
[1] https://www.chromium.org/developers/linux-technical-faq/
[2] https://source.chromium.org/chromium/chromium/src/+/main:chrome/installer/linux/common/repo.cron;drc=4a8573cb240df29b0e4d9820303538fb28e31d84
[3] https://source.chromium.org/chromium/chromium/src/+/main:chrome/installer/linux/common/apt.include;l=372;drc=e49e09e1f9c4aa566f9534d6af832b3175d53687
[4] https://www.google.com/intl/en_uk/chrome/?platform=linux
[5] https://source.chromium.org/chromium/chromium/src/+/main:remoting/host/installer/linux/debian/postinst;drc=d6cdf9b877055ca55cb7064dcf2c40c0513d8eee;l=128
Updated•1 year ago
|
Comment 2•1 year ago
|
||
Please note that what Chrome does is quite controversial in itself. I'm not sure we should mimic what they're doing, although yes, the Ubuntu situation is annoying.
Updated•11 months ago
|
Description
•