The standard apt does not support installing recommends. But this is often useful, especially if make certain dependencies of a meta-package recommends only.


The policy says that recommends should be installed along with dependencies. We should support that accross all frontends. It's also usefull for meta-packages because it means that e.g. openoffice2 can be removed from ubuntu-desktop (if it is only a recommends for it). In addition people should get new recommends/depends when they upgrade to a new ubuntu version.

Use cases

1. Alice does not want to have evolution installed but also does not want to remove ubuntu-desktop. Because evolution is only a recommended package by ubuntu-desktop this will work.

2. Bob installs totem and it recommends a bunch of codecs that are installed as well when he selected it.


apt needs to be modified to install recommends by default in the default pkgPolicy engines isImportantDep() implementation. There needs to be a "--without-recommends" for apt-get install (and a permanent config option) to make sure that people can opt-out of this. aptitude and synaptic needs to be modified to not implement this feature on their own but to use the libapt implmentation. adepts/libapt-fronts policy engine needs to be modified to make use of this as well. Python-apt needs to be looked at as well.


Extend apts pkgPolicy to include a option to support making recommends important dependencies. Make sure that apt checks for new recommends when the package is upgraded. This is not trivial because we want to preserve currently satisfied recommends, even if the format of the recommends changed slightly (A >= 1 to A >= 2) and the same time install recommendations that have been added to the new version of the package. Moreover, it is probably desirable to avoid removing packages in order to satisfy recommendations (e.g., due to a Conflicts asserted by the recommended package).

It should be possible for the user to op-in/op-out for recommends. Synaptic would have to be modified in the "Show changes" dialog to contain addional controls for install/remove etc. Ideally this would allow an individual Recommendation to be overridden or ignored.

For apt-get, we should make sure that "apt-get install foo bar-" work as expected, where foo recommends bar.

Actually, there is a plan for adept to replace the preview dialog with a "resolve" one (Which includes fiddling with package states and preferences).

It might be worth considering to add something the the GUI to get the information about what packages are installed as hard-dependencies and what packages are installed as "weak" dependencies.


Making pkgPolicy follow recommends is easy, making sure that the upgrade case is correct is more difficult (aptitude has code that could cover this, but it needs support from apt to do so; note that it may be possible to make this code simpler and more correct by replacing the complicated "subsumption" relation with a comparison between package names, possibly checking if either package Provides the other).

To get the upgrade case correct it should be enough to compare the current recommends list with the recommends list in the candidate. Anything that is new in the list is a candidate for installting. We may check in addition (if the package is not installed already) if this package is already a recommendation for some other installed package. If this is the case the user is probably not interessted in this package and it can be skipped.

If it turns out that the above mechanism is too simple we should should keep track of what packages the user explictly removes that are violating a Recommends. This isn't quite the same problem as keeping track of what the user explicitly installed; rather, it's isomorphic to the case where the user installs A which -Recommends-> B but instructs the system not to install B. There should be a new "Manual-Removed" tag in /var/lib/apt/extended_states to keep track of those removals and a new field in the pkgDepCache for it.


Some initial code is available at

Open issues in the current code

On upgrade new recommends are not considered (even with the modified pkgPolicy code). But if this recommends code is used for meta-packages this is a important thing to do. We could simply compare the recommendsList of the installed package and the list from the newly installed one and only suggest the new recommends by default. That should solve the upgrade issue.

Implementation status

This code is in apt now (including the the above approach for upgrade problem). There is also APT::Install-Recommends-Section that can be set to a certain section and only this section will be considered as a "install-recommends-by-default". We use this with the new section "metapackages" to avoid having to cleanup all recommends (and do this at the edgy+1 cycle early on).


PhillipSusi: If I understand this correctly, it is implemented in libapt now, and the add applications applet uses libapt, so if the config file is set up correctly, the add applications applet will auto install recommends? Can we get the applet to use an alternate config file that is set up to auto install recommends for ALL sections instead of just metapackages?

Also it would be very nice it rather than auto installing, it would prompt the user to install, giving them the option to decline some packages but with the default action to install. Then maybe prompt the user to install Suggested packages with the default action to not install. At least for synaptic, aptitude, and apt; the simple add programs interface probably should just stick to auto installing recommends.


RecommendsSupport (last edited 2008-08-06 16:13:55 by localhost)