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 :)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
