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:
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"; >
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++
# 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
UPDATE 3: Tried
# apt-get build-dep -o APT::Get::Build-Dep-Automatic=true coreutils
and this time
# apt-get autoremove
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.