| |||||||||||||
Debian "sid" users beware of the dpkg 1.16.2 uploadDebian "sid" users beware of the dpkg 1.16.2 uploadPosted Mar 15, 2012 6:54 UTC (Thu) by geofft (subscriber, #59789)In reply to: Debian "sid" users beware of the dpkg 1.16.2 upload by mtelleria Parent article: Debian "sid" users beware of the dpkg 1.16.2 upload > 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.
(Log in to post comments)
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 :-)
|
|||||||||||||