Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
    
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. –  Faheem Mitha Apr 24 at 18:25
    
Similar askubuntu.com/q/180504/15729 –  Faheem Mitha Apr 24 at 18:27
    
In the first comment, I meant to write "apt does not seem..." –  Faheem Mitha Apr 24 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 at 18:53

2 Answers 2

up vote 3 down vote accepted

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.

share|improve this answer

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…

So,

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

gcj-jre-headless

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

and

ant

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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