(un)markauto tries to remove packages unnecessarily

Bug #173904 reported by Heinrich Kruger
8
This bug affects 2 people
Affects Status Importance Assigned to Milestone
aptitude (Ubuntu)
Incomplete
Low
Unassigned

Bug Description

Binary package hint: aptitude

On gutsy, using aptitude unmarkauto or aptitude markauto, to change the automatically installed status of a package
that does not have any other packages dependent on it, causes aptitude to remove the package.

For example:
$ aptitude search ~neukleides
i A eukleides - Euclidean geometry drawing language
i xeukleides - System for drawing and viewing Euclidean geometry figures

xeukleides depends on eukleides, I can mark eukleides as not automatically installed without any problems:
$ sudo aptitude unmarkauto eukleides
[...]
$ aptitude search ~neukleides
i eukleides - Euclidean geometry drawing language
i xeukleides - System for drawing and viewing Euclidean geometry figures

And I can mark eukleides as automatically installed again:
$ sudo aptitude unmarkauto eukleides
[...]
$ aptitude search ~neukleides
i A eukleides - Euclidean geometry drawing language
i xeukleides - System for drawing and viewing Euclidean geometry figures

No packages depend on xeukleides. When I try to mark xeukleides as automatically installed, aptitude wants to remove xeukleides:
$ aptitude -s markauto xeukleides
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done
The following packages are unused and will be REMOVED:
  eukleides xeukleides
0 packages upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
Need to get 0B of archives. After unpacking 872kB will be freed.
Do you want to continue? [Y/n/?]
Would download/install/remove packages.

I now remove xeukleides:
$ sudo apt-get remove xeukleides
[...]
The following packages were automatically installed and are no longer required:
  eukleides
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
  xeukleides
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0B of archives.
After unpacking 254kB disk space will be freed.
Do you want to continue [Y/n]? Y
(Reading database ... 160896 files and directories currently installed.)
Removing xeukleides ...

Now no packages depend on eukleides, I try to mark eukleides as not automatically installed and aptitude wants to remove it:
$ aptitude -s unmarkauto eukleides
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done
The following packages are unused and will be REMOVED:
  eukleides
0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0B of archives. After unpacking 618kB will be freed.
Do you want to continue? [Y/n/?]
Would download/install/remove packages.

I'm using aptitude version 0.4.6.1:
$ aptitude --version
aptitude 0.4.6.1 compiled at Sep 15 2007 09:21:46
Compiler: g++ 4.1.3 20070831 (prerelease) (Ubuntu 4.1.2-16ubuntu1)

NCurses version: 5.6
libsigc++ version: 2.0.17

Revision history for this message
Rolf Leggewie (r0lf) wrote :

> $ aptitude -s unmarkauto eukleides

This also "works" when omitting the -s, IOW, doing the real thing, not a simulation.

It looks like the removal of the still-automarked package is done before aptitude can unmark it. Confirming with low priority as aptitude emits a list of what it intends to do before actually doing it.

Changed in aptitude:
importance: Undecided → Low
status: New → Triaged
Revision history for this message
Rolf Leggewie (r0lf) wrote :

The easiest way to reproduce this is (assuming that so far neither xeukleides nor eukleides are installed)

"sudo aptitude install xeukleides && sudo apt-get remove xeukleides && sudo aptitude unmarkauto eukleides"

The expected behaviour would arguably be that eukleides is unmarked and kept on the system.

Revision history for this message
Rolf Leggewie (r0lf) wrote :

xeukleides has been removed from ubuntu after gutsy. Do we have another test case to reproduce this?

Changed in aptitude:
assignee: nobody → r0lf
status: Triaged → Incomplete
Revision history for this message
Heinrich Kruger (heindsight-deactivatedaccount) wrote :

i just used eukleides and xeukleides as an example - because they were packages I knew I could easily add and remove, this behaviour can be seen with any automatically installed packages:
Assuming package foo is automatically installed, once all packages depending on foo have been removed, trying to run aptitude unmarkauto foo, causes foo to be removed instead of being unmarked and kept on the system as I would expect. Interestingly using aptitude to remove the last package depending on foo (where foo is marked autoinstalled) causes foo to be removed too, while apt-get does not remove foo but simply warns that nothing depends on foo and that it can be removed.

If you're looking for another test case (assuming neither pi nor libcln5 is installed already), do
aptitude install pi
apt-get remove pi
aptitude unmarkauto libcln5
although any other autoinstalled package will do just as well.
Incidentally, i originally noticed this behaviour under Gutsy, but the same happens in Hardy...

Revision history for this message
Rolf Leggewie (r0lf) wrote :

confirming the pi testcase

Changed in aptitude:
assignee: r0lf → nobody
status: Incomplete → Triaged
Rolf Leggewie (r0lf)
summary: - (un)markauto tries to remove packages
+ (un)markauto tries to remove packages unnecessarily
Daniel Hartwig (wigs)
no longer affects: aptitude (Debian)
Revision history for this message
Rolf Leggewie (r0lf) wrote :

Still reproducible in lucid and trusty with "sudo aptitude install pi && sudo apt-get remove pi && sudo aptitude unmarkauto libcln6"

Actual result: libcln6 has been uninstalled
Expected result: libcln6 should still be installed

Revision history for this message
Rolf Leggewie (r0lf) wrote :

aptitude behaves very differently these days. Personally, I preferred the old ways. Would you consider the current behaviour as having fixed the problem you described here?

Changed in aptitude (Ubuntu):
status: Triaged → Incomplete
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.