Bug#572364: apt doesn't forget auto-install state on package removal; interacts badly with dpkg -i

[Stuart Prescott <stuart+debian@nanonanonano.net>]

Package: apt
Version: 0.7.25.3
Severity: minor

Removing a package leavesh information about the package still in
/var/lib/apt/extended_state which means that subsequently installing the
package manually with dpkg -i doesn't remove this information and the (now
manually) installed package is incorrectly listed as automatically installed
leading to incorrect package removal by a subsequent apt-get autoremove/aptitude
run.

e.g. in a clean sid chroot:

  apt-get -o APT::Install-Recommends=true install git-core
  # package "less" is installed automatically

  apt-get remove git-core
  apt-get autoremove

  aptitude show less | head -2
    Package: less
    State: not installed

  # so far so good, except...

  grep -A1 less /var/lib/apt/extended_states
    Package: less
    Auto-Installed: 1

  dpkg -i /var/cache/apt/archives/less_436-1_i386.deb

  aptitude show less | head -3
    Package: less
    State: installed; will be removed because nothing depends on it
    Automatically installed: yes

  apt-get autoremove
  # removes less as promised but probably not desired

So the stale extended_states information hangs around and causes issues in this
(admittedly small) corner case. It seems unnecessary for these extended states
to be preserved after package removal and it seems odd to require that the
user run "dpkg -i foo.deb ; apt-mark unmarkauto foo" every time they manually
install a package just in case there is stale extended state information hanging
around.

While I've illustrated this using apt-get, the same behaviour is seen when using
aptitude given that automatic removals is now part of apt itself.

cheers
Stuart

(micah pointed this out on #debian-devel and I managed to reproduce this.
He promptly ran away and left me to report the bug :)