2

For the second time now, I've just run apt upgrade and had this happen:

[...] Setting up google-chrome-stable (48.0.2564.116-1) ... update-alternatives: using /usr/bin/google-chrome-stable to provide /usr/bin/x-www-browser (x-www-browser) in auto mode [...]

I am pulling chrome with deb http://dl.google.com/linux/chrome/deb/ stable main . My understanding of apt is a but shaky but generally isn't this the type of action which should only happen when first installing a package, or when using dpkg reconfigure? It's extremely annoying and feels un-apty that I have to reset my preferred browser every time I apt upgrade.

After the upgrade, this is what update-alternatives is showing me:

$ update-alternatives --config x-www-browser There are 3 choices for the alternative x-www-browser (providing /usr/bin/x-www-browser). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/google-chrome-stable 200 auto mode 1 /usr/bin/chromium 40 manual mode 2 /usr/bin/google-chrome-stable 200 manual mode 3 /usr/bin/iceweasel 70 manual mode Press enter to keep the current choice[*], or type selection number:

I find this table rather confusing, but thanks to this question I believe I understand the first (0) entry is just used to select "auto" mode, and the listed binary indicates which choice will be used. The thing is, I'm 99% sure I used update-alternatives to switch this back to my preferred browser (iceweasel) after the last upgrade, so it should have been in "manual mode". x-www-browser was certainly opening iceweasel before this upgrade.

Is the output of apt upgrade indicating I was somehow mistaken and this was already in auto mode, even though it was opening iceweasel? Or is this the result of bad practices on the part of the chrome maintainers, and it's resetting to auto mode on every upgrade?

Improve this question
2
  • The priority is the reason for the (mis)selection. Commented Feb 28, 2016 at 22:20
  • But why would it be reset to auto mode? Do I need to manually change the priority for this to actually be persistent? I found some documentation for changing priority but it effectively means re-creating the alternatives entry manually, which suggests it's not something that's meant to be required for end users... and how do I know chrome's not just going to reinstall the alternatives entry next time? Commented Feb 28, 2016 at 22:31

2 Answers 2

Reset to default
2

The postinst of the Chrome package doesn't to anything out of the ordinary. It just calls update-alternatives --install. This changes the link in /etc/alternatives only if the alternative is currently in auto mode and the newly installed version has a higher priority than the current setting.

update-alternatives doesn't know or care whether the package was freshly installed or updated. The postinst script calls it in all cases. This is the desired behavior: an update of a package could change the priority of some of its alternatives.

If the alternative is changing, the only explanation is that it was already in auto mode before. It may have returned to auto mode if you temporarily removed the package that includes the current manual setting, i.e. if you temporarily removed iceweasel. On the other hand, upgrading iceweasel does not affect a manual setting, because the prerm script of iceweasel correctly only removes the alternative if it's being uninstalled or deconfigured and not if it's being upgraded.¹

¹ The converse is not true: the prerm of google-chrome-stable has a bug, it removes the alternative unconditionally, so that if you upgrade the package and had the alternative manually set to /usr/bin/google-chrome-stable, it will return to auto mode. Once again, this bug only triggers if the alternative was manually set to Chrome, it doesn't affect what happens if the alternative was manually set to something else.

Improve this answer
2
  • Well, x-www-browser was opening iceweasel immediately before this upgrade. The only way I see that could be the case is if this latest chrome update bumped their alternatives priority from sub-70 to 200. I suppose it's possible I previously changed this config by reinstalling with a custom priority, instead of using 'manual mode', and the bug you mentioned reset it to 200? I don't recall doing that and not sure why I would, but it seems like plausible explanation. Commented Feb 28, 2016 at 22:41
  • The key detail here for me is "This changes the link in /etc/alternatives only if the alternative is currently in auto mode and the newly installed version has a higher priority than the current setting.". The part that wasn't obvious is this will cause it to change also if the link had been pointed elsewhere without using update-alternatives, thus leaving the link group in "auto mode". See my answer for an explanation of what I think happened here, but I think I'll accept this answer as it gave all the necessary background that led me in the right direction. Thanks!. Commented Feb 29, 2016 at 2:20
1

The postinstall script which controls this was mentioned in Gilles' answer; I did some digging and found the debian chrome postinst script here. The section controlling this behavior hasn't changed since it was written in 2013, so a change in priority is ruled out.

I did some experimentation with the update-alternatives --install lines from the script and determined the message I saw is indeed only generated if the mode was previously "auto". I also discovered another non-obvious behavior. If an alternative is in "manual mode", and the symlink at /etc/alternatives/x-www-browser is then pointed to another binary by the user rather than using the alternatives system, update-alternatives will automatically recognize the change and continue to track the configuration (assuming that binary also has an entry in the link group). But if the alternative is set to "automatic mode", manually re-pointing the link will cause update-alternatives to no longer track the configuration, and reinstalling an alternative will reset it based on the priority.

I have to conclude I either previously modified this behavior by reinstalling the 'alternative' with a lower priority, or, more likely, manually created a new symlink without changing from "auto mode". I will say the logic behind the '200' priority as explained in the linked script is completely ridiculous, so it wouldn't surprise me if I modified the priority just on principle. ;-)

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.