Package: upgrade-reports Version: woody -> sarge Severity: critical Justification: breaks the whole system
Hi, about a week ago I took the plunge and upgraded one of my machines from Woody to Sarge. Apart from the official packages I also had some packages from backports or compiled from source. After replacing woody in sources.list with sarge, I did an apt-get upgdate and after that an apt-get dist-upgrade. As expected quite a number of packages were scheduled for being upgraded. What was a bit unexpected was that there were also a large number of packages scheduled for removal. I aborted to make a backup of /etc/ and to direct the output of apt-get into a file so that I would be able to install later on the packages that had been removed. This way, I thought, everything would go smoothly. Unfortunately, that was not the case. The upgrade ended half-way through telling me that there was an undefined symbol Perl_gthr_key_ptr. Going from there I found out with Google's help that there had previously been similar bugs classified when dist-upgrading from woody to sarge (278417, 278495 and 279232, possibly others, apparently there is no way search to search for a string in bug reports present in the BTS system). These were classified as RC. Apparently the abortion of the upgrade is due to the fact that perl is in an inconsistent state out of which the system cannot free itself. And indeed 'dpkg -l perl*|grep ^i' tells me that perl, perl-modules and perl-suid are version 5.8.4 -5, installed but unconfigured (iU) and that perl-base is 5.6.1-8.8 (ii), perl-t k is 800.025-2 (iU) and perlmagick is 5.4.4.5-1woody (ii). As advised on #debian, I tried via aptitude if that was able to fix the mess, but quickly found out that it would most likely only make matters worse. Thus I backed off and have not touched the system since. I have the following information still on file and can make it available on request. I hope you understand that I do not include it yet in this bug report for reasons of privacy and so as not to flood the BTS. - tar file of /etc (and /home) before the upgrade pre-upgrade /var I have unfortunately no copy of - output of apt-get on what packages to install and which to remove - output of dpkg -l right after the failed upgrade - and of course the system itself in its current state My assumption is that from this it should be possible to somehow reconstruct what packages were installed at the time I tried the upgrade and thus analyze what triggered this failure. Best regards Rolf Leggewie -- System Information: Debian Release: 3.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.26.desktop041204 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]