[Bug 985852] Re: libapt-pkg regression: infinite loop on processing certain Pre-Depends

[Launchpad Bug Tracker]

This bug was fixed in the package apt - 0.8.16~exp12ubuntu10

---------------
apt (0.8.16~exp12ubuntu10) precise-proposed; urgency=low

  [ Malcolm Scott ]
  * apt-pkg/packagemanager.cc:
    - Fix a regression in the pre-depend handling: where a pre-depend option
      other than the first specified is already installed, apt-get enters an
      infinite loop (LP: #985852)

  [ Michael Vogt ]
  * apt-pkg/packagemanager.cc:
    - add APT::pkgPackageManager::MaxLoopCount to ensure that the
      ordering code does not get into a endless loop when it flip-flops
      between two states

  [ David Kalnischkies ]
  * apt-pkg/cacheset.cc:
    - actually return to the fallback modifier if we have detected we
      should for packagenames which look like modifiers (Closes: #669591)
      LP: #982716
 -- Michael Vogt <michael.vogt at ubuntu.com>   Fri, 20 Apr 2012 11:10:12 +0200

** Changed in: apt (Ubuntu)
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/985852

Title:
  libapt-pkg regression: infinite loop on processing certain Pre-Depends

Status in “apt” package in Ubuntu:
  Fix Released

Bug description:
  Summary: a typo in apt-pkg/packagemanager.cc means that certain Pre-
  Depends cannot be processed, causing libapt-pkg to hang.

  Details: I have a custom package whose control file contains
    Pre-Depends: grub-pc | grub
  When I attempt to install this on a system which has grub installed already but not grub-pc, apt-get hangs indefinitely, in an infinite loop inside pkgPackageManager::SmartUnPack.

  This situation, in which one of the pre-depends is already installed,
  should be handled in the block starting at apt-
  pkg/packagemanager.cc:612 ("Look for easy targets: packages that are
  already okay").  However this fails to inspect anything but the first
  pre-depend option as line 615 refers to Start rather than Cur
  (repeatedly looking at the first package in the iterator, not the
  current value of the iterator).

  The error has been replicated a few lines further down, which means
  the subsequent code also fails to resolve the situation (e.g. in the
  case that the second pre-depend is simultaneously being installed
  explicitly).

  I attach a debdiff.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/985852/+subscriptions