Olá a todos,
Estou avaliando o OpenSUSE Leap 16 para uma estação de trabalho de produção e tenho uma dúvida específica sobre como o gerenciador de pacotes lida com remoções manuais durante as atualizações do sistema.
Nos meus testes anteriores, após remover alguns aplicativos, um zypper dup subsequente acabou restaurando esses pacotes removidos. Eu busco um sistema que respeite estritamente as decisões do administrador local em relação a desinstalações.
Minhas dúvidas são:
- Existe uma forma definitiva de garantir que pacotes removidos manualmente (especialmente aqueles vinculados a padrões de desktop ou recomendações) nunca retornem automaticamente em um
zypper dup?
- O sistema atualmente suporta desinstalação manual persistente por padrão, ou o resolvedor sempre tratará componentes ausentes de um padrão como erros a serem “corrigidos”?
Por exemplo, ao remover o LibreOffice, pois uso outro suíte, durante um update qualquer o sistema traz novamente o LibreOffice.
Não são opções, sudo zypper addlock, sudo zypper locks, sudo zypper up/dup --no-recommends. Pois apenas escondem os pacotes, mais eles continuam lá. aparecendo no terminal, como algo pendente.
OBS: Estou com uma Vm para fazer todas as validações possíveis antes de migrar pro bare metal. Essa vm montada sobre uma ISO baixada em meados de 23/07/2026, está assumindo corretamente o meu desejo. Removi e não reinstalou mais.
Contudo esse não parece ser o comportamento padrão da distribuição. Que seria a retomada dos pacotes removidos. Mais caso tenha havido alguma mudança nessa política de instalação e a partir de agora o libzypp/libsolv respeite as remoções feitas pelo usuário sem sobrepor políticas de patterns seria perfeito.
Caso alguém tenha essas informações ou saiba de algo neste sentido agradeceria imensamente.
Agradeço antecipadamente por qualquer esclarecimento técnico.
Olá e bem-vindo ao fórum! 
No Leap, você deve usar apenas zypper up ou zypper patch; o dup é indicado para distribuições como o Tumbleweed.
Você pode bloquear pacotes com zypper al <nome_do_pacote> ou configurar o sistema para não instalar pacotes recomendados (no-recommends).
Nota: Utilizando o Google Tradutor.
Olá @malcolmlewis,
Gostaria de detalhar melhor o comportamento que observei nesta VM de testes com o openSUSE Leap 16.0 para alinharmos o entendimento técnico.
Analisando a saída do comando para o padrão office (usei um aleatório como teste), temos o seguinte:
Informação para padrão office:
Repositório : repo-oss (16.0)
Nome : office
Versão : 20170506-bp160.1.1
Arquitetura : x86_64
Fornecedor : openSUSE
Pacote Buddy : patterns-office-office-20170506-bp160.1.1.x86_64
Instalado : Sim (automaticamente)
Visível ao usuário : Sim
Resumo : Office Software
Descrição : Office software for your desktop environment including LibreOffice.
Conteúdo :
S | Name | Type | Dependency
—±--------------------±--------±-----------
i | pattern:office | pattern | Requerido
| libreoffice | package | Recomendado
| libreoffice-calc | package | Recomendado
| libreoffice-draw | package | Recomendado
| libreoffice-impress | package | Recomendado
| libreoffice-math | package | Recomendado
| libreoffice-writer | package | Recomendado
O Ponto Central da Dúvida.
1 Diferença de comportamento em ISOs recentes: Há menos de 40 dias, baixei uma ISO oficial do Leap 16.0, diretamente no site e fiz o mesmo processo de instalação realizado para o atual sistema. observei que a mesma lista de pacotes vinha marcada integralmente como “Requerida”, o que forçaria a reinstalação de todos eles em qualquer comando de atualização (up ou dup). No entanto, nesta instalação recente com a mesma imagem oficial, eles aparecem como “Recomendados”.
2 O comportamento padrão definitivo: Gostaria de confirmar se o comportamento oficial do sistema é manter esses pacotes de aplicativos como “Recomendados” (permitindo que fiquem ausentes quando desmarcados) ou se o cenário padrão da distribuição e virem como “Requerido”.
3 Perspectiva de longo prazo e migração (zypper dup): Para um ambiente de produção de longo prazo, o procedimento de rotina é o uso do zypper up. Contudo, em algum ciclo futuro será necessário migrar de versão (ex: do Leap 16.0 para o 16.1) utilizando o zypper dup. Se o metapacote do padrão permanece registrado como instalado, qual é o mecanismo esperado para que a migração não reintroduza em massa os componentes que o administrador removeu ou optou por não instalar?
Agradeço antecipadamente pela clareza sobre como essa arquitetura se comporta em horizontes de longo prazo.
Suspeito que você tenha se deparado com a versão remasterizada do Leap 16.0, que foi lançada com alterações e melhorias adicionais.
A atualização da distribuição não deve ser um problema; se estiver instalada e tiver novas recomendações, será atualizada.
Veja também https://en.opensuse.org/Portal:16.0
Você pode consultar o instalador e os perfis do Agama para obter um processo mais preciso https://agama-project.github.io/docs/user/profile/working_with_profiles
Nota: Utilizando o Google Tradutor.