14

When using aptitude, the list of changed packages sometimes has a single character in curly brackets behind some package names. The man-page has two examples of them but does not explain them (version 0.6.10-1).

I have noticed {b}, {a} and {u} so far. The former one seems to show up when running aptitude install and tries to re-install packages I deleted (e.g. via debfoster, how can I disable that?), the latter two seem to have something to do with automatic dependency resolution.

What do these characters mean, are there others, and what implications do they have for other operations? Is that extra information available to dpkg or apt?

8

These aren't documented. My guess is that a is for an automatic install, u is for an (automatic?) upgrade and b is for packages installed to fix broken packages.

This would mean debfoster is removing packages it is not supposed to, note that the website says:

As of 2006-01-01, debfoster is officially deprecated.

Possibly this has developed bugs over the years due to changes in the apt system. You could confirm this by doing aptitude search '~b' after using debfoster (it will list broken packages).

Note that apt now supports an automatic flag for dependency packages and has apt-get autoremove. With aptitude you can also do aptitude remove '~g'.

Update

Playing around with aptitude, it turns out that if I press ? when I get the Do you want to continue? [Y/n/?] prompt, I get the following message:

In the list of actions to be performed, some packages will be followed by one or
more characters enclosed in braces; for instance: "aptitude{u}".  These
characters provide extra information about the package's state, and can include
any combination of the following:

  'a': the package was automatically installed or removed.
  'b': some of the package's dependencies are violated by the proposed changes.
  'p': the package will be purged in addition to being removed.
  'u': the package is being removed because it is unused.

So it seems that b is supposed to be for a broken package. Although, in your case it seems to be a bug that it is displayed if there is nothing broken. I can't recreate the issue, but aptitude does try to reinstall packages I remove with apt-get just without anything in braces.

Also note that aptitude keep-all is probably safer than removing /var/lib/aptitude/pkgstates

  • ps auxf shows that debfoster just calls apt-get --purge remove pkg1 pkg2 etc., search '~b' returns nothing, and the next aptitude install reinstalls pgk1 pkg2 etc. – finite graygreen Mar 24 '14 at 16:12
  • 1
    @finitegraygreen, I guess its not for broken packages then! You could try using aptitude why to find what is happening or just the --show-why option. – Graeme Mar 24 '14 at 16:29
  • @finitegraygreen, what was the the conclusion here? Was b for broken after all or did aptitude why turn up some other reason? I'm sure I will come across this again at some point, would be nice to know... – Graeme Apr 9 '14 at 21:19
  • Well, the conclusion is "These aren't documented." And I stopped the interference between apt-get and aptitude by forcing amnesia on the latter via deleting /var/lib/aptitude/pkgstates. Otherwise I'd still get apt-get remove pkg; aptitude why pkg "Unable to find a reason to install"; aptitude install then installs pkg. – finite graygreen Apr 10 '14 at 10:24
  • @finitegraygreen, turns out there is a description of what these mean. See the updated answer. – Graeme Apr 10 '14 at 11:14
1

This post by the aptitude author explains {a} and {u}:

  • {a} means that the package will be additionally installed besides what you asked for.
  • {u} means that the package is not being used by the system and will be removed.

Unfortunately it doesn't explain {b}.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.