Open Bug 1918128 Opened 1 year ago Updated 5 months ago

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)

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.

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

Depends on: 1926556
No longer blocks: 1884336
See Also: → 1884336

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.

Component: Release Automation: Packaging → Release Automation
You need to log in before you can comment on or make changes to this bug.