It turns out that it depends on how you launch your browser. In Ubuntu MATE, launching your browser from the top panel causes it to be parented by mate-panel. When Chrome launches gdebi-gtk (which is a Python script), python ends up parented by init (PID 1). On the other hand, if you launch your browser by clicking the Google Chrome icon in the MATE dropdown menu as seen below, the parenting differs.
Incredible
This whole article, and how long the issue went unfixed does leave me feeling pretty jaded and sad about the quality of Linux on the desktop in general.
It was a bug affecting a specific .deb installer only when using a specific desktop environment and that only happened in specific circumstances. There are probably many similar bugs in every single other operating system out there.
The good part is that someone that was bothered by it was able to go in there and fix it, instead of needing to wait for someone else to do so.
It was a bug affecting a specific .deb installer only when using a specific desktop environment and that only happened in specific circumstances.
Sure but… I don’t think I could come up with a more happy path / common scenario than: “first time user opens firefox to install chrome” if I tried.
EDIT: It does they weren’t using the default firefox that comes installed so yeah a weird one
I think Linux people (for the most part) being technical enough to just revert to dpkg -i is probably the reason why it went unfixed for so long. I feel like I’d have just done the exact same thing. So like you said, good on the author for fixing!
I bet that’s why this bug lingered on for so long: the scenario is certainly common, but that’s anything but the happy path. I just tried to google it. Virtually every result that comes up either covers only the terminal installation, or covers both the terminal installation and the simple “double-click the .deb file” variant, just in case the latter doesn’t work.
That’s no coincidence, either. There are a bunch of good, or at least working frontends to package managers (aptitude, Synaptic), but they’re not exactly simple, one-click install tools. Simple, one-click install tools have been a long sought-after goal of just about every “let’s make Linux friendly for non-technical users” initiative, so one of them comes up every couple of years or so (it used to be every major release or so back in the early/mid ‘00s, nowadays it’s less common because app stores are holy grail aroma of the day).
However, most of these tools tend to lack the features that actual (as opposed to hypothetical) Linux users would need, and they never really fit the way Linux software has been distributed. So their actual use is, erm, sporadic at best. Many of them sucked from day 1 (I mean, I don’t think I’ve ever seen one of these things install a package and not break something). Staying away from them is one of the first things you learn, usually the hard way.
Consequently, almost nobody who can fix bugs (or at least recognise and report them) uses them, so bugs linger for years because nobody who can provide a meaningful bug report is even aware of them. Since backwards compatibility is not a thing in the Linux userland, they bitrot rather quickly, too.
Sure but… I don’t think I could come up with a more happy path / common scenario than: “first time user opens firefox to install chrome” if I tried.
IMO “launching a non-snap browser from mate-panel and trying to install a downloaded .deb file using gdebi” is not that much of a common scenario. It seems like a non-trivial amount of steps to reproduce. Also, a first-time user would probably not be using mate-panel/gdebi and Firefox would probably be installed as a snap in Ubuntu.
I think Linux people (for the most part) being technical enough to just revert to dpkg -i is probably the reason why it went unfixed for so long.
That’s absolutely true. With my Debian Maintainer hat on, I find it really hard to cater to non-technical users but it’s one of the most important things we can do to help the adoption of Linux on the desktop.
dpkg is the low-level packaging utility that higher-level tools like apt-get and apt use. It only handles package management operational primitives like installing, uninstalling or verifying a single, specific package – so no dependency resolution, no automatic verifying/auditing (i.e. unless you specifically do it manually) and so on.
20+ years ago high-level package management packed with Debian and its derivatives worked only with files in APT repositories, a conscious design choice at the time. So none of the high-level frontend tools (apt-get, dselect before it, if anyone remembers that) handled local packages. Technically, you were never supposed to install a .deb file from someplace other than an APT repository but that didn’t stop people from doing it, and dpkg was the only way to do it.
This hasn’t been the case in a long time, apt will handle local packages just fine, and give you all the high-level apt goodies that dpkg can’t give you.
On Linux distros shipping things that obviously couldn’t have been tested:
Yes, I feel like this happens a bit often. It’s the bane of Linux distros. Of course, nobody can be blamed for doing charity work for free, nor for shipping something that, yes, is broken, but isn’t your fault. Or even if it was, it is still noble to try to keep a ship afloat that was abandoned upstream. I’m talking about bugs that slip through the cracks (literally – it’s so often in the interface between things), only to get discovered about 1 year too late when things first come together – “integration bugs”, maybe. Thank goodness for rolling release distros, I say.
(Yes, I wish more people used rolling release distros. Just to dispel that, are there going to be less bugs in software that was packaged half a year ago? Apart from security bugs, of course not! Your choices are really between old and new bugs. What I have learnt is this: If you want to report a bug, it helps nobody if it’s already fixed, and you still have to wait for the fix, whereas reporting a new bug is appreciated and has a good chance of coming your way soon if you are on a rolling release.)
What about automatic tests? Are distros running the tests that come with the software, or is it enough that it compiles?
Not that this would be easy to make an automated test for, let alone have the fantasy to test that it also works when parented by pid 1. But when modifying GDebi to use pkexec instead of gksu, that’s at least an opportunity to think that thought. I think this example was special in that there was an actual change, as opposed to when bumping a dependency silently breaks a slew of other packages that depend on it.
I wish there was a rolling release distro that had checks in place to prevent accidental breakage, including packages that break other packages.
More classic examples would be if the newest kernel breaks the Nvidia driver (I remember a time when this happened like clockwork), wait with bumping that kernel until Nvidia works with it again. And if Glibc breaks Teams (as it did 3 releases in a row at the height of corona times), also wait it out.
Incredible
This whole article, and how long the issue went unfixed does leave me feeling pretty jaded and sad about the quality of Linux on the desktop in general.
It was a bug affecting a specific .deb installer only when using a specific desktop environment and that only happened in specific circumstances. There are probably many similar bugs in every single other operating system out there.
The good part is that someone that was bothered by it was able to go in there and fix it, instead of needing to wait for someone else to do so.
Sure but… I don’t think I could come up with a more happy path / common scenario than: “first time user opens firefox to install chrome” if I tried.
EDIT: It does they weren’t using the default firefox that comes installed so yeah a weird one
I think Linux people (for the most part) being technical enough to just revert to
dpkg -iis probably the reason why it went unfixed for so long. I feel like I’d have just done the exact same thing. So like you said, good on the author for fixing!I bet that’s why this bug lingered on for so long: the scenario is certainly common, but that’s anything but the happy path. I just tried to google it. Virtually every result that comes up either covers only the terminal installation, or covers both the terminal installation and the simple “double-click the .deb file” variant, just in case the latter doesn’t work.
That’s no coincidence, either. There are a bunch of good, or at least working frontends to package managers (aptitude, Synaptic), but they’re not exactly simple, one-click install tools. Simple, one-click install tools have been a long sought-after goal of just about every “let’s make Linux friendly for non-technical users” initiative, so one of them comes up every couple of years or so (it used to be every major release or so back in the early/mid ‘00s, nowadays it’s less common because app stores are holy grail aroma of the day).
However, most of these tools tend to lack the features that actual (as opposed to hypothetical) Linux users would need, and they never really fit the way Linux software has been distributed. So their actual use is, erm, sporadic at best. Many of them sucked from day 1 (I mean, I don’t think I’ve ever seen one of these things install a package and not break something). Staying away from them is one of the first things you learn, usually the hard way.
Consequently, almost nobody who can fix bugs (or at least recognise and report them) uses them, so bugs linger for years because nobody who can provide a meaningful bug report is even aware of them. Since backwards compatibility is not a thing in the Linux userland, they bitrot rather quickly, too.
IMO “launching a non-snap browser from mate-panel and trying to install a downloaded .deb file using gdebi” is not that much of a common scenario. It seems like a non-trivial amount of steps to reproduce. Also, a first-time user would probably not be using mate-panel/gdebi and Firefox would probably be installed as a snap in Ubuntu.
That’s absolutely true. With my Debian Maintainer hat on, I find it really hard to cater to non-technical users but it’s one of the most important things we can do to help the adoption of Linux on the desktop.
Reminder that you probably never want
dpkg -ithese days. You can useapt install ./thing.debnowWhat’s the difference,?
dpkgis the low-level packaging utility that higher-level tools likeapt-getandaptuse. It only handles package management operational primitives like installing, uninstalling or verifying a single, specific package – so no dependency resolution, no automatic verifying/auditing (i.e. unless you specifically do it manually) and so on.20+ years ago high-level package management packed with Debian and its derivatives worked only with files in APT repositories, a conscious design choice at the time. So none of the high-level frontend tools (
apt-get,dselectbefore it, if anyone remembers that) handled local packages. Technically, you were never supposed to install a.debfile from someplace other than an APT repository but that didn’t stop people from doing it, anddpkgwas the only way to do it.This hasn’t been the case in a long time,
aptwill handle local packages just fine, and give you all the high-levelaptgoodies thatdpkgcan’t give you.Packaging bugs in Ubuntu do not reflect the state of all Linux distros ;)
Whew kudos to the author for seeing this over the line.
On Linux distros shipping things that obviously couldn’t have been tested:
Yes, I feel like this happens a bit often. It’s the bane of Linux distros. Of course, nobody can be blamed for doing charity work for free, nor for shipping something that, yes, is broken, but isn’t your fault. Or even if it was, it is still noble to try to keep a ship afloat that was abandoned upstream. I’m talking about bugs that slip through the cracks (literally – it’s so often in the interface between things), only to get discovered about 1 year too late when things first come together – “integration bugs”, maybe. Thank goodness for rolling release distros, I say.
(Yes, I wish more people used rolling release distros. Just to dispel that, are there going to be less bugs in software that was packaged half a year ago? Apart from security bugs, of course not! Your choices are really between old and new bugs. What I have learnt is this: If you want to report a bug, it helps nobody if it’s already fixed, and you still have to wait for the fix, whereas reporting a new bug is appreciated and has a good chance of coming your way soon if you are on a rolling release.)
What about automatic tests? Are distros running the tests that come with the software, or is it enough that it compiles? Not that this would be easy to make an automated test for, let alone have the fantasy to test that it also works when parented by pid 1. But when modifying GDebi to use pkexec instead of gksu, that’s at least an opportunity to think that thought. I think this example was special in that there was an actual change, as opposed to when bumping a dependency silently breaks a slew of other packages that depend on it.
I wish there was a rolling release distro that had checks in place to prevent accidental breakage, including packages that break other packages.
Example: OpenVPN hasn’t worked for a year in many distros after glib2-2.76: https://github.com/OpenVPN/openvpn3-linux/issues/171
More classic examples would be if the newest kernel breaks the Nvidia driver (I remember a time when this happened like clockwork), wait with bumping that kernel until Nvidia works with it again. And if Glibc breaks Teams (as it did 3 releases in a row at the height of corona times), also wait it out.