Como remover um grupo de pacotes Debian desnecessários?

6

Ao criar softwares, às vezes preciso instalar bibliotecas, binários, etc., que são necessários apenas para compilar o pacote, mas depois esqueço-os de removê-los, por isso acabo tendo que limpar vários pacotes de uma só vez; mesmo aqueles que eu não quero remover.

Analisar os arquivos de log para encontrar os pacotes exatos é sub-ótimo e um problema real se os pacotes tiverem idade suficiente. Existe uma maneira de facilitar essa tarefa?

    
por Braiam 24.04.2014 / 19:16

3 respostas

5

Eu sugeriria usar tags de usuário, que é uma característica do aptitude (apt binary não tem isso) ajudaria com isso. Ao instalar os pacotes, adicione a opção --add-user-tag ao instalar os pacotes, por exemplo:

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

e para removê-los basta usar:

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

Você também pode remover a tag ao longo do caminho com --remove-user-tag build-dep-package .

Mas isso representa um problema, e se o mesmo pacote tiver as duas tags? Bem, basta usar as condições e / ou não para evitar que isso aconteça:

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

Para manipular vários pacotes com tags diferentes, use ou:

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

Por isso é muito útil a longo prazo, não encontrei uma maneira de listar todas as tags ativas atuais.

    
por 24.04.2014 / 19:16
2

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.

    
por 24.04.2014 / 20:38
2

Isso não ajudará em seus pacotes dev existentes, mas para uso futuro, considere usar mk-build-deps (no pacote devscripts ) para gerar um meta-pacote para as dependências.

mk-build-deps precisa apenas do nome de um pacote disponível ou de seu arquivo de controle. Este último é útil se o seu pacote não estiver (ainda) disponível ou se você estiver adicionando novas dependências.

Ele pode instalar o meta-pacote gerado (mais dependências) para você, se você quiser.

Como de costume, detalhes completos na página de manual depois de instalá-lo.

    
por 12.01.2016 / 15:33