Aptitude - using together with Synaptic and Apt-get

		Stable document
		You can comment on this document by clicking on the discussion tab. You can edit the live version of this document: Aptitude - using together with Synaptic and Apt-get

Abstract

Help for Debian users using more than one package manager. If you do not use Aptitude exclusively, it may attempt to remove packages that you do not wish to remove. Here is some help for newbies (and other Debian users) for managing this problem.

1 Introduction

Early versions of Debian used Apt-get for package management. Nowadays, Aptitude is the recommended CLI (Command Line Interface) package manager, and Synaptic is the recommended GUI (Graphical User Interface) package manager. There is also an interactive form of Aptitude which uses the ncurses interface.

Aptitude maintains a separate database of installed packages so that it knows which packages have been installed manually and which packages have been installed automatically as "dependencies" or "recommends". Aptitude automatically removes the automatically installed packages when they are no longer needed. This helps to prevent the build-up of un-needed packages ("cruft" - http://en.wikipedia.org/wiki/Cruft) on your hard disc.

This is fine if you use only Aptitude as your package manager. If you have ever used another package manager, Aptitude's database may become unreliable and Aptitude may attempt to remove packages that you do not wish to remove. Here are some suggestions for managing the use of Aptitude together with other package managers.

2 Running Aptitude after using another package manager

(Adapted from a post by Florian Kulzer at http://lists.debian.org/debian-user/2006/12/msg00288.html.)

2.1 Check Aptitude's internal database

Aptitude remembers intended actions, even if you change the package states and/or configuration settings.

If you have been using another package manager since you last used Aptitude, you should check Aptitude's intended actions before proceding. Whenever in doubt, check Aptitude's intentions with a simulated ("-s") run to fix ("-f") packages that it thinks are broken. Since -s simulates it is safe to avoid the prompting by saying yes with ("-y").

# aptitude install -sfy

If Aptitude wrongly wants to remove packages, apply one of the fixes below.

2.2 Global fix of Aptitude's internal database

Tell Aptitude to "keep-all" installed packages. This cancels all scheduled actions on all packages (including installation, removal, or upgrade).

# aptitude keep-all

 

Tip: 

If you ever need to avoid trouble, "aptitude keep-all" restores sane behavior.

 

2.3 Fix just the "automatically installed" flag

A common problem is that some packages may be wrongly marked as automatically installed. Aptitude may wrongly want to remove some of them. You can fix this by telling Aptitude to unmark ("unmarkauto") all such packages that are currently installed ("--schedule-only '~i'"). This command is more specific than "aptitude keep-all" and may be sufficient to fix the problem. It has the advantage that it does not modify any other "sticky" flags (eg "hold" or "forbid-version").

# aptitude unmarkauto --schedule-only '~i'

Aptitude tries to react immediately to changes in package states, including the "automatically installed" ("A") flag. If you want to run several successive "(un)markauto" commands to change/fix your system then you have to use "--schedule-only" to keep Aptitude from doing something unintended halfway through the operation.

If you want to be on the safe side you can always run "aptitude install -sfD" afterwards to check whether any of your previous commands has caused Aptitude to schedule unwanted actions. The "-D" option shows brief explanations of automatic installations and removals.

# aptitude install -sfD

If this shows any unwanted actions, you can always run "aptitude keep-all" to revoke all scheduled actions. Of course, this will also remove any "markauto", "hold" and "forbid-version" specifications that you may have flagged manually. If you are fine-tuning to this extent, you should probably install one of the "aptitude-doc-??" packages and check the documentation in /usr/share/doc/aptitude/html.

# aptitude keep-all

If you are running Aptitude interactively, another helpful stop-gap measure is temporarily to set a configuration file option directly with the "-o" option. (See /usr/share/doc/aptitude/html/en/ch02s04s05.html#configKeep-Unused-Pattern after installing the aptitude-doc-en package or one of the other language versions.) The term "~T" matches any package. Set the configuration file option to keep any packages marked as unused.

# aptitude -o Aptitude::Keep-Unused-Pattern='~T'

3 The Sudo pitfall (Sarge only)

In Sarge, the location of aptitude's configuration file depends on whether it is run as root or with "sudo" (unless you change your sudo set_home configuration). This can lead to inconsistent behavior. "sudo -H" takes care of this. Sudo's -H (HOME) option sets the HOME environment variable to the homedir of the target user.

$ sudo -H aptitude ...

 

Tip: 

You can define an alias for "sudo -H aptitude" to ensure safe typing:

alias saptitude='sudo -H aptitude'

 

This problem has been fixed in Etch.

4 Upgrade non-agressively

If Aptitude runs into problems when trying to upgrade packages (eg because the updated versions of some dependencies are still missing) it will normally propose the least harmful action first (e.g. keeping a few packages at their presently installed version). However, if you run another upgrade command after the harmless actions have been carried out, then aptitude will assume that you want it to be more aggressive. "keep-all" helps again, as well as CTRL + U or "Cancel Pending Actions" in interactive mode.

# aptitude upgrade
# aptitude keep-all
# aptitude upgrade

5 Upgrading from Sarge to Etch

(Adapted from a post by Osamu Aoki at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401317.)

Upgrading from Sarge stable to Etch using the Sarge version of Aptitude may be a problem if your system has a large number packages installed. The Sarge version of Aptitude has fewer features than the Etch version. Here is a suggested process that does not try to update the Desktop. The idea is to remove big dependency-rich sets of packages in Sarge and reinstall them in Etch using the newer version of Aptitude.

Step 1. Kernel upgrade in sarge (2.2, 2.4 --> 2.6 with udev).

Step 2. Remove all Desktop Environment in Tasksel placing "-" over it and do "g". This removes many files but at least you know what has been removed. You never need these while upgrading. (Actually cyclic dependency keeps some packages.)

Step 3. Point /etc/apt/sources.list to etch (include nonfree contrib if GFDL doc packages and others are needed.) Do "aptitude update". (Do not worry about warning.)

Step 4. Partial upgrade to Etch (aptitude, tasksel and its dependencies).

# aptitude install aptitude tasksel

Step 5. Start new aptitude and set Desktop task.

# aptitude
 ... press "+" over "End-user" in "Tasks".  So we get new full
     etch desktop. 
 ... press "U" to upgrade all and try resolving with "e" and "!" "g"
 ... press "Y" for `/etc/dpkg/dpkg.cfg'
 ... After everythng, do it again. press "+" over "End-user". 
 ... No problem (no red resolver).  "g"
 ... Hmmm... Let's remove Obsolete interactively.  "g".

This is a much saner upgrade than upgrading with Desktop.

6 Install without bloat

By default, Aptitude installs "recommended" packages as well as just "dependencies". This means that you may end up installing more packages than you would expect if you used other package managers. You can avoid this by using the "-R" (or "--without-recommends") option.

# aptitude install -R ...

7 Get rid of unused packages

You can tell Aptitude to purge any packages that are no longer required by any installed package.

--purge-unused

8 Appendix A: Licence

Copyright (c) 2006-2007 Chris Lale. chrislale AT users DOT berlios DOT de

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License."

This work is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This work is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this work; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA

Go to NewbieDOC index