When building software, I sometimes need to install libraries, binaries, etc. which are only required to build the package but then I forget about removing them, so I end having to cleanup several packages at once; even those that I don't want to remove.

Parsing the log files to find the exact packages is suboptimal and a royal pain if the packages are old enough. Is there a way to facilitate this task?

  • I assume you are talking about packages that are installed when doing (for example) apt-get build-dep ..., right? I think apt does not mark these as auto-installed by default, though an option to do so might be useful, because they are only required for a short time. apt does seem to have an option to say "consider all these packages I'm installing now to be automatically installed", but if it did so, that might be useful here. Apr 24, 2014 at 18:25
  • Similar askubuntu.com/q/180504/15729 Apr 24, 2014 at 18:27
  • In the first comment, I meant to write "apt does not seem..." Apr 24, 2014 at 18:40
  • @FaheemMitha not only for build-dep (through the example was mostly focused on it), because I work with some projects that are not included in the repositories.
    – Braiam
    Apr 24, 2014 at 18:53

3 Answers 3


I would suggest using user tags, which is a characteristic of aptitude (apt binary doesn't have this) would help with that. When installing packages add the --add-user-tag option when installing the packages, for example:

sudo aptitude --add-user-tag build-dep-package build-dep package

and to remove them just use:

sudo aptitude remove '?user-tag(build-dep-package)'

You can also remove the tag along the way with --remove-user-tag build-dep-package.

But this pose a problem, what about if the same package has both tags? Well, you just use the and/not conditionals to prevent that from happening:

sudo aptitude remove '?and(?user-tag(build-dep-package),?not(?user-tag(wanted-packages))'

To manipulate several packages with different tags use or:

sudo aptitude remove '?or(?user-tag(build-dep-package),?user-tag(wanted-packages)'

Through this is very useful in the long run, I haven't found a way to list all the current active tags.


I found a post by David Kalnischkies in the blog post UNDO APT-GET BUILD-DEP (REMOVE BUILD DEPENDENCIES)

For those who don't know, David is the main apt maintainer, and has been so since 2009 or thereabouts, so it is a safe bet he knows what he is talking about.

DonKult • 3 years ago

Before you try this insane commandline, try this option: APT::Get::Build-Dep-Automatic

like in apt-get build-dep -o APT::Get::Build-Dep-Automatic=true srcpkg1 srcpkg2 …

If that works for you and you want to have it permanent: echo APT::Get::Build-Dep-Automatic "true"; > /etc/apt/apt.conf.d/99markbuilddepauto

I don't remember in which APT version it was added, but it must be old enough for at least a couple of ubuntu releases… btw: The default value was switched to "false" at 2009-02-09 in ubuntu.

Oh, and just for the record: Insane, because it installs aptitude to use the same functionality which is already provided by an installed application shipped with APT: apt-mark.

But as always, with 6 hours of coding you can avoid reading the manpages for 5 minutes…


apt-get build-dep -o APT::Get::Build-Dep-Automatic=true srcpkg1 srcpkg2...

is probably a reasonable way to go. I had no idea this option existed. As of right now I have not been able to find it in apt documentation. I'll update if I do.

However, note also the Debian bug report aptitude: APT::Get::Build-Dep-Automatic is not honored. The title says it all.

UPDATE: Having tested this, it doesn't seem to work. I did

# apt-get build-dep -o APT::Get::Build-Dep-Automatic=true g++

and then

# apt-get autoremove

but it returned nothing. Maybe I'm missing something. I'll leave this answer alone for the moment.

UPDATE 2: I see in /var/lib/apt/extended_states that the packages are correctly marked as Auto-Installed: 1. So, I must be using autoremove wrong.

UPDATE 3: Tried

# apt-get build-dep -o APT::Get::Build-Dep-Automatic=true coreutils

and this time

# apt-get autoremove

uninstalled dh-buildinfo gperf libacl1-dev libattr1-dev correctly.

So, why did the previous attempt not work? I'm not sure, but hypothesis - the top level packages provided virtual packages which were required by a manually installed packages. So


Provides: java-gcj-compat-headless, java-runtime-headless, java-virtual-machine, java1-runtime-headless, java2-runtime-headless, java5-runtime-headless



Depends: default-jre-headless | java5-runtime-headless | java6-runtime-headless | java7-runtime-headless, libxerces2-java

So there is an overlap here - namely java5-runtime-headless. Bottom line - this may have been an unfortunately chosen example.


This won't help with your existing dev packages, but for future use, consider using mk-build-deps (in the devscripts package) to generate a meta-package for the dependencies.

mk-build-deps needs just the name of an available package, or its control file. The latter is useful if your package isn't (yet) available or if you are adding new dependencies.

It can install the generated meta-package (plus dependencies) for you if you want.

As usual, full details in the manual page once you've installed it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .