Aptitude - using together with Synaptic and Apt-get
From NewbieDOC
- Chris Lale
- chrislale AT users DOT berlios DOT de
Go to NewbieDOC index
Revision History
Revision 1.0 | 11th December 2006 | Revised by Chris Lale | ||||||||||||||
Initial release. | ||||||||||||||||
| ||||||||||||||||
Revision 1.1 | 25th November 2007 | Revised by Chris Lale | ||||||||||||||
Adapted for newbiedoc package by adding Revision History, Abstract and Appendix for Licence. | ||||||||||||||||
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 IntroductionEarly 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 databaseAptitude 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 databaseTell Aptitude to "keep-all" installed packages. This cancels all scheduled actions on all packages (including installation, removal, or upgrade). # aptitude keep-all 2.3 Fix just the "automatically installed" flagA 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-agressivelyIf 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 bloatBy 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 packagesYou can tell Aptitude to purge any packages that are no longer required by any installed package. --purge-unused 8 Appendix A: LicenceCopyright (c) 2006-2007 Chris Lale. chrislale AT users DOT berlios DOT de
Go to NewbieDOC index |