Bug#604222: apt: list uninstalled packages as automatically installed
On Sun, Nov 21, 2010 at 10:44, Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote:
> In a clean chroot:
> (squeeze64-instest)root@parapluie-7:~# apt-get install bacula-server
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages were automatically installed and are no longer required:
> sqlite libsqlite0 postgresql-client postgresql-client-8.4 postgresql-client-common
> libpq5 sqlite3
> Use 'apt-get autoremove' to remove them.
> The following extra packages will be installed:
[…]
> sqlite3 tcpd ucf
[…]
> The following NEW packages will be installed:
[…]
> python2.6-minimal sqlite sqlite3 tcpd ucf
> 0 upgraded, 56 newly installed, 0 to remove and 0 not upgraded.
> Need to get 35.7 MB of archives.
> After this operation, 117 MB of additional disk space will be used.
> Do you want to continue [Y/n]?
As you can see here, if you look closely:
APT wants to install these packages, but also knows that this is useless.
Thats properly because APT tried to follow an or-group by choosing the
first option to find out later, that this route can't be taken and succeeded
with second option instead.
The problem is, that APT doesn't undo all the install requests it did on the
dead-end route so it still wants to install them without needing them…
(as it discovers the conflict in a completely different sub-tree)
Undoing the changes is in the current implementation simply impossible.
I think aptitude solves it by creating full copies of the depcache to work on
them which is obviously an easy solution, but also very wasteful in terms of
memory usage (it nukes autoremoves also automatic in the same run,
so this one can't happen anyway).
This particular incident could be solved much easier through:
The code could check if a package which is going to be installed is
marked as 'garbage' by autoremove and simply doesn't schedule it for
installation then. (I will give it a try later)
Note that you didn't see most of the 'extra' installed packages because
of a dead-end route as they are "hidden" in the or-group:
As long as a package is part of an or-group it is not garbage, even if
other packages satisfy the or-group, too.
So you need a situation like
A depends on B | C
B depends on D
D depends on E
E breaks B
In that case APT installs A, D, E and C and marks
D and E as garbage as they are alone in the dark.
If B would still be here, D and E would be hidden by it.
In this very specific case, APT can't really decide if it should
install the sqllite3, mysql or pgsql director which origins in bacula-sd
as it Recommends bacula-sd-tools - for this one APT chooses
the provider bacula-sd-* at random¹ -- all other dependencies seems to be
or-groups which prefer the sqlite3 backend, so for consistence
this recommends should prefer the sqlite3 backend by
changing it to 'bacula-sd-sqlite3 | bacula-sd-tools', too.
(cc'ed the bacula maintainers so they can have a look)
Best regards,
David Kalnischkies
¹ not really random, its mysql but just because its listed first in the
Packages file as it is alphanumerical sorted…
Reply to: