Package: apt Version: 0.7.25.3 Severity: serious Hi, I have been testing upgrades from lenny to sid with a tool similar to piuparts. I ran into many (~80) strange failures, where apt takes a wrong decision about which packages to upgrade. All the logs are available from http://people.debian.org/~lucas/logs/2010/08/05/pkg-upgrade/ Here are the various cases: package-not-upgraded/: The package under test was not upgraded during apt-get dist-upgrade. That is always because upgrading it would have required the removal of another package. However, in the case of library packages being removed to permit the upgrade, I was wondering whether it was possible to trick apt into upgrading the package. package-uninstalled/: The package under test was removed during apt-get dist-upgrade. package-uninstalled/no-removal/ <= that's where the serious issues are The package under test was removed during dist-upgrade, but no removal was neded to get it back! It should really have been upgraded together with the other packages. There are quite a lot of failures related to emacs packages, so they are separated in the logs. package-uninstalled/removals/: A package was removed to permit the upgrade. I'm wondering if in some cases, it would have made sense to auto-detect the correct solution. Thanks,
apt-get upgrade
apt-get dist-upgrade
This will reduce the number of issues.
apt-get install apt (to upgrade apt) apt-get upgrade apt-get dist-upgrade And I don't really see any difference (I haven't tested all the packages that were failing). Good examples of packages that fail are pyrex-mode and python-application. Both get removed during apt-get dist-upgrade, but can be installed without removing any package after that. L.
The reason is that dpkg breaks emacs21 and that confuses APT. APT views
it like this:
pyrex-mode => python-mode => emacs21
The following solution is ignored, because python-mode is already
installed:
pyrex-mode (Depends: python-mode or emacs22) => emacs22
The following solution is ignored because emacsen is already installed
(provided by emacs21):
pyrex-mode => python-mode (Depends: emacs22 | emacsen) => emacs22
Because dpkg breaks emacs21, the chosen dependency chain becomes invalid
and the packages will be removed.
jak-thinkpad:/home/jak/Desktop/dh-autoreconf# aptitude dist-upgrade
The following NEW packages will be installed:
cpp-4.4{a} dash{a} diffutils{a} g++-4.4{a} gcc-4.4{a} insserv{a} libc-bin{a} libc-dev-bin{a} libdb4.7{a} libdb4.8{a} libdpkg-perl{a} liblzma2{a} libmpfr4{a}
libreadline6{a} libstdc++6-4.4-dev{a} python2.6{a} python2.6-minimal{a} sensible-utils{a} xz-utils{a}
The following packages will be REMOVED:
libdb4.5{u} libxcb-xlib0{u} python2.5{u} python2.5-minimal{u}
The following packages will be upgraded:
bash binutils build-essential cpio cpp cpp-4.3 debianutils diff dpkg{b} dpkg-dev e2fsprogs g++ g++-4.3 gcc gcc-4.3 gcc-4.3-base gnupg gpgv grep libc6 libc6-dev
libgdbm3 liblocale-gettext-perl libpam-modules libpam-runtime libstdc++6-4.3-dev libtext-charwidth-perl libtext-iconv-perl libx11-6 libxcb1 perl perl-base
perl-modules python python-minimal readline-common sed sysv-rc util-linux
The following packages are RECOMMENDED but will NOT be installed:
bash-completion gnupg-curl libalgorithm-merge-perl libc6-i686 libldap-2.4-2 manpages-dev netbase
39 packages upgraded, 19 newly installed, 4 to remove and 0 not upgraded.
Need to get 63.8MB of archives. After unpacking 53.9MB will be used.
The following packages have unmet dependencies:
dpkg: Breaks: emacs21 (< 21.4a+1-5.7) but 21.4a+1-5.6 is installed.
The following actions will resolve these dependencies:
Remove the following packages:
1) emacs21
2) pyrex-mode
3) python-mode
Accept this solution? [Y/n/q/?] ^C
At least those two work now with the latest commit in debian-experimental-ma.------------------------------------------------------------ revno: 2032 committer: Julian Andres Klode <jak@debian.org> branch nick: debian-experimental-ma timestamp: Fri 2010-08-06 23:33:55 +0200 message: * apt-pkg/depcache.cc: - Only try upgrade for Breaks if there is a newer version, otherwise handle it as Conflicts (by removing it) (helps for #591881). diff: === modified file 'apt-pkg/depcache.cc' --- apt-pkg/depcache.cc 2010-07-14 20:59:43 +0000 +++ apt-pkg/depcache.cc 2010-08-06 21:33:55 +0000 @@ -1425,10 +1425,13 @@ VerIterator Ver(*this,*I); PkgIterator Pkg = Ver.ParentPkg(); - if (Start->Type != Dep::DpkgBreaks) + + + if (PkgState[Pkg->ID].CandidateVer != *I && + Start->Type == Dep::DpkgBreaks) + MarkInstall(Pkg,true,Depth + 1, false, ForceImportantDeps); + else MarkDelete(Pkg,false,Depth + 1, false); - else if (PkgState[Pkg->ID].CandidateVer != *I) - MarkInstall(Pkg,true,Depth + 1, false, ForceImportantDeps); } continue; } === modified file 'debian/changelog' --- debian/changelog 2010-08-02 19:02:01 +0000 +++ debian/changelog 2010-08-06 21:33:55 +0000 @@ -8,6 +8,11 @@ * apt-pkg/cdrom.cc: - fix off-by-one error in DropBinaryArch + [ Julian Andres Klode ] + * apt-pkg/depcache.cc: + - Only try upgrade for Breaks if there is a newer version, otherwise + handle it as Conflicts (by removing it) (helps for #591881). + -- Michael Vogt <michael.vogt@ubuntu.com> Fri, 30 Jul 2010 17:37:14 +0200 apt (0.7.26~exp12) experimental; urgency=low
Great! I'll install the experimental version instead of the unstable one next time I run my tests. (probably not before ~1 week)
I reran those tests (package-uninstalled/no-removal) using the latest
commit in APT's debian-experimental-ma branch; and got:
Emacs cases (26)
================
Fixed (13/26):
* anthy-el
* bbdb
* css-mode
* eldav
* html-helper-mode
* mell
* migemo-perl
* php-elisp
* post-el
* prime-el
* pyrex-mode
* python-mode
* rdtool-elisp
Packages depending on emacs21 | emacsen (8/26) [0]:
* bhl
* crypt++el
* ecb
* elib
* etalk
* gnuserv
* remembrance-agent
* rnc-mode
Failed to install newer emacs (5/26) [1]:
* c-sig
* gnus
* ifile-gnus-el
* remember-el
* suikyo-elisp
[0] emacs22 | emacsen might work
[1] depends on emacs22 | ... | emacsen; but emacs22 is not pulled.
Non emacs cases (11)
====================
Fixed (1/11):
* python-application
Imagemagick (2/11):
* libautotrace-dev
* octave-image
Textlive (5/11):
* dvi2ps
* itrans-fonts
* latex-cjk-japanese-wadalab
* tex4ht-common
* tex4ht
Others (3/11):
* conkeror (xulrunner-1.9 stuff)
* libgpevtype-dev
* python-migrate (python-codespeak-lib becomes virtual in squeeze)
For texlive cases:
I. textlive-common Conflicts texlive-base-bin; causes
textlive-base-bin to be removed
II. texlive-common is not needed anymore and can be removed.
The correct solution would be to remove texlive-common instead of
texlive-base-bin.
Summary
=======
Fixed: 14/37
Remaining: 13/37
-----------------
Total: 37/37
(some comments i thought i had already sent… sorry) 2010/8/7 Julian Andres Klode <jak@debian.org>: I think you mean in II. texlive-base-bin as it is not available in testing. All listed packages still depend on this package non the less, so they are non-installable in unstable/testing, right? (most or-depend on tetex-bin, which is gone too). Fixed by the FixByInstall commit. We will see if it will work out in real world or comes back and hit us horrible hard into our a… ;) Depends on libmimedir-gnome-dev which was provided by libmimedir-gnome0-dev before but this package is now dropped. Instead libmimedir-gnome-dev is now a real package which is noticed "too late" by APT. Could be easily worked around by introducing a dummy package libmimedir-gnome0-dev dropping the provides. Fixing it in APT looks a bit harder to me as i guess it would require to answer the question if a virtual or a real package is preferable in general… … which seems to be the same culprit as above in reverse. In my reduced testcase is python-migrate btw scheduled for upgrade, but python-central python-codespeak-lib python2.5 python2.5-minimal are removed… btw Lucas, is your script available somewhere? Best regards David Kalnischkies
Yes, http://svn.debian.org/viewsvn/collab-qa/debcluster/scripts/tasks/instest.rb?revision=1760&view=markup But as you will see it is quite hackish. - Lucas
There's already an open APT bug about upgrade issues (#591882, Cced). Ideally, we would have one bug per type of issue, but I'm having problem distinguishing the various issues here. - Lucas
Hi, #603680 looks quite similar to #591882 to me. cheers, Holger
I don't think this procedure makes sense to test lenny→squeeze upgrades. It might be a testbed for apt to improve squeeze→wheezy, but for lenny→squeeze we should rely on lenny's apt, and fix packages to work well with that. So I don't think there's a serious bug in apt here, individual package upgrade issues should be fixed in those specific packages at this point. Cheers, Julien