Encontrei um post de David Kalnischkies no post do blog
UNDO APT-GET CONSTRUÇÃO-DEP (REMOVE BUILD DEPENDENCIES)
Para quem não sabe, David é o principal mantenedor do jogo, e tem sido assim desde 2009 ou por aí, então é seguro que ele saiba do que está falando.
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…
Então,
apt-get build-dep -o APT::Get::Build-Dep-Automatic=true srcpkg1 srcpkg2...
é provavelmente um caminho razoável para ir. Eu não sabia que essa opção existia. A partir de agora, não consegui encontrá-lo na documentação do apt. Eu atualizarei se eu fizer.
No entanto, observe também que o aptitude do relatório de erros do Debian: APT :: Get :: Build-Dep-Automatic não é aceito . O título diz tudo.
UPDATE: Tendo testado isso, parece que não funciona. Eu fiz
# apt-get build-dep -o APT::Get::Build-Dep-Automatic=true g++
e depois
# apt-get autoremove
mas não retornou nada. Talvez eu esteja perdendo alguma coisa. Deixarei esta resposta em paz por enquanto.
UPDATE 2: vejo em /var/lib/apt/extended_states
que os pacotes estão marcados corretamente como Auto-Installed: 1
. Então, devo estar usando autoremove
errado.
ATUALIZAÇÃO 3: Tentei
# apt-get build-dep -o APT::Get::Build-Dep-Automatic=true coreutils
e desta vez
# apt-get autoremove
desinstalou dh-buildinfo gperf libacl1-dev libattr1-dev
corretamente.
Então, por que a tentativa anterior não funcionou? Não tenho certeza, mas hipótese - os pacotes de nível superior forneciam pacotes virtuais que eram exigidos por pacotes instalados manualmente. Então
gcj-jre-headless
Provides: java-gcj-compat-headless, java-runtime-headless, java-virtual-machine, java1-runtime-headless, java2-runtime-headless, java5-runtime-headless
e
ant
Depends: default-jre-headless | java5-runtime-headless | java6-runtime-headless | java7-runtime-headless, libxerces2-java
Portanto, há uma sobreposição aqui - ou seja, java5-runtime-headless
. Bottom line - este pode ter sido um exemplo infelizmente escolhido.