Bug#60488: internal error with --reinstall; analysis and possible strategy

[<james@netcsi.com>]

Package: apt
Version: 0.3.18

I have two potato systems here, one i386, one powerpc.  They have the
following package versions installed:

Package		i386		powerpc
apt		0.3.18		0.3.18
libc6		2.1.3-7		2.1.3-2
gzip		1.2.4-33	1.2.4-33
debianutils	1.13.2		1.13.2

They both have the problem: If I try

  # apt-get --reinstall install gzip debianutils

it will proceed to fetch all the packages, then immediately abort with:

  E: Internal Error, Could not perform immediate configuraton

(sic).  As it turns out this error comes from about line 565 of
packagemanager.cc.  (This is modified source so the line is not exact;
in any case it's the second occurrence of 'configuraton' in the file.)

After adding loads and loads of extra debugging noise to libapt-pkg I
managed to reconstruct the following sequence of events:

  1) DepCache::Init marks everything already installed in the 'Keep'
     state as a default.
  2) TryToInstall (in apt-get) tries to mark debianutils and gzip for
     install.  DepCache::MarkInstall leaves their Mode as MarkKeep
     because the target version and installed version are the same.
     Noticing this, it sets a flag on them to make sure they get
     reinstalled even though they're marked the same as if they were
     held back, because --reinstall is being used.
  3) PR::InstallProtect also tries marking both those packages for
     install, but there's no change.
  4) The packages are ordered: first debianutils, then gzip.
  5) PM::SmartUnpack is called on debianutils.  All of
     debianutils' Pre-Depends (libc6) are ready.
  6) debianutils is essential, so it has to be configured ASAP
     (immediate configuration).  PM::SmartConfigure is called.
  7) PM::SmartConfigure calls PM::DepAdd to make sure all
     debianutils' depends and pre-depends are ready.
  8) PM::DepAdd looks at the depends and pre-depends and decides
     that the current version of libc6 satisfies all the
     dependencies.
  9) Now PM::SmartUnpack is called on gzip.  It too finds libc6
     to be OK.
  10) Since gzip is also essential, it too gets SmartConfigure'd.
  11) SmartConfigure calls DepAdd.
  12) DepAdd first goes past the first branch of its main loop
      tests (checking for 'now' packages that satisfy the
      dependencies).  I think this is where it goes wrong.
  13) Then it decides that the version it's looking at is not
      worth bothering over because it meets the following 3
      conditions:
        the package is marked keep()
        it's all set up and doesn't need anything done
        it's the target version (not necessary but doesn't
          stop it given the other two)
      This is in a branch marked 'not the install version'.
      I find this rather odd, maybe the bug is actually
      here?
  14) Since that's the only possible target version that
      can be downloaded, the dependency is unsatisfied and
      gzip is judged unconfigurable, and the whole thing
      just dies.

I thought the problem was with the tests for IsNow().  I kep
seeing tests like 'IsNow(Pkg) == true' but in the code for
IsNow() you can see it returns a somewhat arbitrary nonzero
number for true.  Seems though that in C++ or the dialect of it
that apt uses the type 'bool' has '==' overridden to compare truth
values, since when I tried 'fixing' that it still didn't work.  So
the bug is somewhere else.

I still think it's silly writing all these ' == false' and
' == true' comparisons when what you're comparing are truth values
to begin with.  You're only going to be giving yourselves RSIs
doing things like that, and possibly introducing obscure bugs.

Anyway, since my investigations haven't *quite* uncovered the bug
yet, I thought someone who knows the code a *bit* better than me,
who took his first look at apt internals yesterday, might be able
to make a bit more sense out of what information I have managed to
bring to light.

--
James Deikun, Techie(tm), CSI Multimedia
The opinions expressed &c.