Como lidar com 'apt-get autoremove' no Ubuntu

2

(Posso listar mais de 20 páginas com perguntas / preocupações semelhantes. Mas não consegui encontrar nenhuma solução. Então, por favor, tenha paciência comigo antes de marcar isso como duplicado.)

Já faz quase três semanas que eu mudei do Windows para o Linux (Ubuntu). Eu tenho tentado encontrar as ferramentas certas para meus aplicativos. Então, eu tenho tentado muitas aplicações diferentes no Linux. Como resultado, eu instalei / removi muitos aplicativos usando apt-get .

Após um desses comandos de instalação / remoção, apt-get sugeriu executar o comando apt-get autoremove . Eu fiz isso e então percebi que ele também removeu alguns dos meus aplicativos de desktop e a aparência do meu ambiente de desktop mudou completamente. Como não sou especialista em Linux, acabei gastando tempo e reinstalando-o!

Foi quando eu decidi nunca mais usar apt-get autoremove . Eu, então, procurei e encontrei o deborphan que foi recomendado para remover pacotes órfãos. Então, ao invés de usar apt-get autoremove , eu estava usando o comando abaixo para me livrar de pacotes indesejados:

sudo deborphan --guess-all | xargs sudo apt-get -y remove --purge

Isso foi muito bem até recentemente que depois de executá-lo, o Qt-Creator parou de compilar meu código C ++ com o erro cannot find -lGL . Foi muito bem antes de usar deborphan . Por sorte, consegui consertá-lo reinstalando o libgl1-mesa-dev package.

Então, infelizmente, esse também foi o fim da minha confiança em deborphan .

Agora, depois de alguns dias sem usar apt-get autoremove nem deborphan , aqui está a longa lista de pacotes que apt sugere para remoção:

 0 upgraded, 0 newly installed, 79 to remove and 0 not upgraded.> The following packages will be REMOVED:   fonts-wine
 geany-plugins-common gir1.2-evince-3.0 gir1.2-gconf-2.0
 gir1.2-nautilus-3.0 gir1.2-poppler-0.18 libboost-atomic1.62-dev  
 libboost-atomic1.62.0 libboost-chrono1.62-dev libboost-chrono1.62.0
 libboost-context1.62-dev libboost-context1.62.0  
 libboost-coroutine1.62-dev libboost-coroutine1.62.0
 libboost-date-time1.62-dev libboost-date-time1.62.0
 libboost-exception1.62-dev   libboost-fiber1.62-dev
 libboost-fiber1.62.0 libboost-filesystem1.62-dev
 libboost-graph-parallel1.62-dev libboost-graph-parallel1.62.0  
 libboost-graph1.62-dev libboost-graph1.62.0 libboost-iostreams1.62-dev
 libboost-locale1.62-dev libboost-locale1.62.0   libboost-log1.62-dev
 libboost-log1.62.0 libboost-math1.62-dev libboost-math1.62.0
 libboost-mpi-python1.62-dev libboost-mpi-python1.62.0  
 libboost-mpi1.62-dev libboost-mpi1.62.0
 libboost-program-options1.62-dev libboost-program-options1.62.0
 libboost-python1.62-dev   libboost-python1.62.0
 libboost-random1.62-dev libboost-regex1.62-dev
 libboost-serialization1.62-dev libboost-serialization1.62.0  
 libboost-signals1.62-dev libboost-signals1.62.0
 libboost-system1.62-dev libboost-test1.62-dev libboost-test1.62.0  
 libboost-thread1.62-dev libboost-timer1.62-dev libboost-timer1.62.0
 libboost-type-erasure1.62-dev libboost-type-erasure1.62.0  
 libboost-wave1.62-dev libboost-wave1.62.0 libboost1.62-dev
 libboost1.62-tools-dev libhwloc-dev libibverbs-dev libieee1284-3:i386 
 libnuma-dev libopenmpi-dev libpython3-dev libpython3.6-dev libwine
 libwine:i386 linux-headers-4.13.0-21 linux-headers-4.13.0-21-generic  
 linux-image-4.13.0-21-generic linux-image-extra-4.13.0-21-generic
 mc-data mpi-default-dev ocl-icd-libopencl1:i386 python-glade2         
 python3-dev python3.6-dev thunderbird-locale-en wine32:i386 wine64

Eu não tenho tempo nem conhecimento para percorrer esta lista e descobrir qual pacote eu realmente preciso e qual está correto para ser removido.

Eu também tentei marcá-los como "manuais" com a esperança de que, após fazer isso, apt-get autoremove possa determinar quais são realmente órfãos e indesejados para serem removidos. Eu usei aptitude keep-all e sempre congela. Descobri que isso é um bug que deveria ser corrigido, mas aparentemente não é.

Pergunta: Qual é a abordagem mais segura para remover aplicativos / bibliotecas indesejados no Ubuntu que não envolve a verificação de todos os pacotes e suas dependências, um por um?

    
por NESHOM 12.03.2018 / 02:55

1 resposta

3

As regras para autoremoval são realmente muito simples.

A resposta específica à sua pergunta " abordagem mais segura para remover aplicativos / bibliotecas indesejados no Ubuntu que não envolve a verificação de todos os pacotes e suas dependências, um por um " é: Deixe o Apt fazer seu trabalho . Você pode fazer isso quando entender melhor como o apt faz suas decisões. Para a maioria dos novos usuários, essa é uma parte normal da curva de aprendizado. Então vamos discutir a lógica do Apt ....

Apt não tem idéia se você está usando um pacote ou não. Não é psíquico. Ele só conhece as dependências de cada pacote e o que você diz. Para que qualquer pacote seja elegível para autoremoval (órfão), ele deve atender a dois critérios :

  1. Deve ser marcado pelo apt como auto (em vez de manual )
  2. Não manual package depende - direta ou indiretamente - do pacote.

Existem três comportamentos complicadores que confundem os usuários.

  1. O Apt lembra quais pacotes você instala explicitamente e marca esses pacotes manual . Todas as outras dependências estão marcadas com auto .

  2. O instalador do Ubuntu marca TODOS os pacotes iniciais em uma nova instalação manual . Isto é para evitar que novas pessoas removam acidentalmente placas enormes do seu sistema.

  3. Os pacotes de kernel funcionam de maneira ligeiramente diferente devido a um pouco de script-fu do Ubuntu.

É isso - duas regras e três comportamentos especiais. Todo o resto é simples lógica antiga.

Vamos dar uma olhada em alguns exemplos comuns para ver como essas regras e comportamentos se aplicam.

Exemplo # 1 : sudo apt install foo libfoo

É bastante óbvio que qualquer coisa chamada libfoo é provavelmente uma dependência de foo . E o apt sabe disso também. No entanto, explicitamente informamos ao apt para instalar o libfoo - ele será marcado como manual e não será qualificado para autoremoval. Se tivéssemos dito apenas sudo apt install foo e deixado apt calcular as dependências, então libfoo seria (corretamente) marcado com auto e se tornaria elegível para autoremoval quando foo fosse removido.

Exemplo # 2 : sudo apt remove ubuntu-desktop

Se você construir um sistema Ubuntu a partir de uma imagem mínima , ou se você instalar pilhas LAMP ou novo Desktop Ambientes após a instalação inicial, então Metapackages como ubuntu-desktop são ótimos - a pilha inteira em um comando. Mas olhe para ele do ponto de vista do apt: Um único pacote manual e dezenas (centenas) de auto dependencies. No momento em que você desinstala o metapacote devido a tentar um aplicativo diferente ... bem, você tem a idéia.

A saída é simplesmente marcar seus principais aplicativos de nível superior como manual :

sudo apt install foo       // Even if foo is already installed
sudo apt-mark manual foo   // Does the same thing
sudo apt-mark auto libfoo  // Makes libfoo eligible for autoremoval someday when foo gets removed
sudo apt remove foo        // Apt will remove foo *regardless* of apt-mark

Lembre-se de que o apt-marking simplesmente informa quais pacotes são seus aplicativos de nível superior não elegíveis para autoremoval - ele NÃO os protege de insensatez humana.

A maneira mais fácil de navegar em uma lista de autoremoval para a maioria das pessoas é simplesmente procurar pelos principais pacotes de aplicativos - seu cliente de e-mail, seu navegador, seu IDE, seu jogo favorito. Procure foo , ignore libfoo . Quando alguém passar e for removido, basta reinstalá-lo - lembre-se de que informar ao sistema para instalar um pacote marca manual . No entanto, , seu caso de uso específico é mais complicado, pois você compila o software e usa -dev packages. Não existe uma solução mágica para você (desculpe) - você deve ter tempo para aprender quais pacotes são importantes para você ... assim como o resto de nós fez.

Caveat : Tudo isso se aplica aos pacotes deb dos repositórios do Ubuntu. Se você adicionar muitos pacotes estranhos de algum outro lugar, então há mais tarefas de limpeza que você deve fazer. Lembre-se de que o apt não possui conhecimento nem controle sobre pip, snap, flatpack, software de aplicativos, binários ou scripts baixados ou código compilado.

    
por user535733 12.03.2018 / 05:24