| |||||||||||||
Debian "sid" users beware of the dpkg 1.16.2 uploadDebian "sid" users beware of the dpkg 1.16.2 uploadPosted Mar 14, 2012 2:46 UTC (Wed) by geofft (subscriber, #59789)Parent article: Debian "sid" users beware of the dpkg 1.16.2 upload
As LWN has reported just a few days ago, Guillem has been pretty conservative about the multiarch dpkg branch, and about the released code based on that branch that's been running in Ubuntu. He's claiming that in addition to the version in experimental, all recent Ubuntu dpkg versions are also likely to exhibit massive breakage. I haven't been following the story (and certainly not the code) closely enough to determine whether he's right, or this is FUD. He may well have a point and nobody knows the dpkg code better than he does, but there's been a lot of lack of transparency in how this branch was going to play out, and I generally trust the Ubuntu folks who snapshotted this branch to have been competent at code-reviewing it too. But, in short, "Debian 'sid' users beware" is an incomplete summary of the claim in this article; "all Ubuntu Natty, Oneiric, and Precise users and all future users of those releases beware" is even more strongly claimed.
(Log in to post comments)
Debian "sid" users beware of the dpkg 1.16.2 upload Posted Mar 14, 2012 9:36 UTC (Wed) by mtelleria (subscriber, #33878) [Link]
I also understand Guillem's fears and the possibility that his
Analysing his announcement, Guillem has pinpointed the CAUSES of 3
1. "You should check for any packages in the status db w/o
2. You should also check in the logs that no package has been
3. Make sure there's no package present (i.e. with status >=
This is a great outcome from Guillem's analysis, but what would be
More precisely I would like someone to confirm my assumptions:
1. The first test I understand it consisits in parsing /var/lib
2. For the second test, which logs can we look at? In case there are
3. The third test also consists in parsing the status file and see if
Then I would keep a backup copy of the status file (in case future problems
Debian "sid" users beware of the dpkg 1.16.2 upload Posted Mar 14, 2012 10:41 UTC (Wed) by angdraug (subscriber, #7487) [Link] This script by Raphael Hertzog should help.
Debian "sid" users beware of the dpkg 1.16.2 upload Posted Mar 15, 2012 6:54 UTC (Thu) by geofft (subscriber, #59789) [Link] > Analysing his announcement, Guillem has pinpointed the CAUSES of 3 possible problems and suggests 3 CHECKS to take before upgrading:If you read closely, Guillem pinpointed the cause of 3 possible problems out of quite possibly many more, and suggests 3 checks to take before upgrading, without guaranteeing that those checks are sufficient to make everything safe. In other words, if you ever ran the current common multiarch dpkg, you have no idea what may have possibly gone wrong. (He also explicitly does not want to have dpkg itself do these checks when being upgraded, on the grounds that the previously-widely-used multiarch implementation was unofficial, and is not interested in reports of what else breaks besides the issues he noticed.) Perhaps, as he claims, the code has not been reviewed enough, and there are in fact more subtle bugs lurking. But perhaps this is FUD, and the fact that I haven't seen Ubuntu in two-and-a-half releases of this code find massive breakage on their users' systems makes me wonder whether they've been lucky or the code is actually quite fine. In the literal sense, there is fear about the so-called unreviewed code, uncertainty about its effects, and doubt as to whether your system is even recoverable. As also mentioned by another commenter, the other active dpkg maintainer, Raphael, posted a script to debian-devel to check for the issues Guillem mentioned, along with a gentle complaint that Guillem sent this email to debian-devel-announce without coordinating with the rest of the dpkg team. Given that Raphael is also active in Ubuntu, I would expect that we'll find that a more polished version of his script gets run on Ubuntu upgrades to this dpkg version.
Debian "sid" users beware of the dpkg 1.16.2 upload Posted Mar 15, 2012 9:22 UTC (Thu) by rhertzog (subscriber, #4671) [Link]
Just a few comments.
1/ Just installing the experimental package will not have created problems. You need to have tried multiarch by adding a supplementary architecture and installing packages form this foreign architecture.
2/ I don't know of any way to trigger the main problem that guillem is referring to... if you managed to install multiple instances of a foreign package it's because it has a Multi-Arch: same field. And that field is not dropped when you remove the package.
So while Guillem is certainly well-intended, imho this announce did not had to look like so scary.
-- Raphael Hertzog
Debian "sid" users beware of the dpkg 1.16.2 upload Posted Mar 15, 2012 12:34 UTC (Thu) by Jonno (subscriber, #49613) [Link] 2/ While it is not possible to have different versions of a package installed, you could have more than one package configured, by simply first removing the old version without using --purge, and then installing the new version from another arch. If one of these versions are Multi-arch: same while the other isn't, you get the problem he describes.
Debian "sid" users beware of the dpkg 1.16.2 upload Posted Mar 15, 2012 13:23 UTC (Thu) by rhertzog (subscriber, #4671) [Link]
Indeed, thank you, that's a way to get in the situation described.
But realistically for this to happen, it means that either have you have removed (without purging) the native version of the package while it wasn't multi-arch aware yet and you later installed a foreign version of the package once it has been converted to multi-arch.
Or you had only a foreign version of the package installed (before its conversion to multi-arch), that you removed and now you installed the native one after its conversion.
Because as soon as you have two versions co-installed at a given time, it means that the field was present.
Anyway, I just reproduced it here (need squeeze + wheezy in sources.list):
So the two problems are real even if relatively unlikely on a typical usage of multiarch.
Again thank you, at least I could test that my script was working as expected :-)
|
|||||||||||||