severity 562398 important Thanks Hi
It also seems quite risky to introduce this change now (see below for my test results). As this bug is only triggered in very rare circumstances and as far as I understand these circumstances can't happen in a stable release, I don't think this issue is really release critical. I'm therefore downgrading this bug. Feel free to upgrade it again if you disagree. Excerpts from John Wright's message of Mon Mai 03 10:15:06 +0200 2010: > On Sun, May 02, 2010 at 03:08:08PM -0600, John Wright wrote: > > Specifically, what happens is that anna unpacks all the packages in one > > batch, and then it configures all of them. But while unpacking another > > version of a package while another vesrion is in an > > unpacked-but-not-configured state is ok, it's not ok to configure a > > package that's already in the configured state. So if a package is in > > the list twice, it fails at the second configure for that package. > > Here's what's happing in libd-i: Upon encountering a Packages stanza > with the same Package field as one it's previously seen, > di_packages_parser_read_name sets the data pointer the rest of the > parsing functions will use to the previously-used di_packages pointer. > At first glance, this would appear simply to prefer packages that appear > later in the Packages file, irrespective of version. Unfortunately, it > appends the di_package to the package list > (&parser->data->packages->list) whether it's a newly allocated one or an > old one. So while only one actual di_package exists for a particular > package name, it might appear multiple times in the list. > > The simple way to fix the anna issue is to make sure we only append > newly allocated di_package objects to the list. But it would be nice to > favor new versions rather than whatever shows up latest in the Packages > file (for example, to facilitate #389430 or LP#234486). > > I've attached a quick reproducer to demonstrate the issue, and a patch. > I would prefer if the version comparison could happen during the > Packages file parsing, rather than after the fact (since this way > requires creating a temporary hash table and traversing the list a > couple of extra times), but that change would seem to be very invasive. > In any case, after pounding my head for a couple of hours, I couldn't > figure out how to do it any better with the current parsing > infrastructure. :) I tested you patch during the BSP in Bern. The patch still applies cleanly to the current libdebian-installer. It also still fixes your test case. But when testing a d-i image with your patch (patched libdebian-installer installed on the build host and in localudebs!) anna fails to download (some) dependencies. The install then fails during clock-setup because tzsetup-udeb is not installed. I'm pretty sure this is related to the patch because it does not happen with the daily images. John did you test your patch in d-i? And did you install the patched libdebian-installer on your build host? If you don't install it on the build host, the first part of the installer will run with the unpatched library. Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1291026376-sup-5...@meteor.durcheinandertal.local
