Ao atualizar o sistema operacional debian em vários hosts ( apt-get dist-upgrade
), vi muitas variações pequenas da mesma tela; quando um arquivo de configuração for modificado, ele informará que uma nova versão está disponível e solicitará que você corrija o problema: você modificou o arquivo e o apt/dpkg não pode integrar de forma confiável suas alterações com a nova versão.
Agora, este menu de opções é diferente entre vários arquivos. Às vezes até dentro do mesmo pacote.
Alguns arquivos terão uma IU de console de "configuração de pacote", outros usarão a saída de console simples. As opções disponíveis na interface do usuário de configuração do pacote nem sempre são as mesmas.
O nome do arquivo modificado/nova versão nem sempre é o mesmo. O local onde o novo arquivo é armazenado nem sempre é o local onde deveria estar (às vezes é em 'tmp'.). O esquema de nomenclatura para o novo arquivo também não é consistente (alguns pacotes usam um nome aleatório, alguns usam -new, outros -dpkg-new e assim por diante).
Alguns pacotes se recusam a dizer onde está o padrão do dpkg. Alguns pacotes não fornecem a versão anterior com extensão dpkg-old ou -old ou -dist ou -dpkg-dist ou -old-nameofpackage, mas outros sim. (Portanto, em alguns casos, você pode mesclar manualmente em 3 vias, em outros casos, não). Alguns pacotes adicionam um útil 'faça uma mesclagem de 3 vias entre as versões' (que é sempre a primeira coisa que tento, pois muitas vezes pode resolver automaticamente o problema: a maioria das alterações nos arquivos de configuração geralmente são apenas correções de erros de digitação nos comentários.
O programa ou a maneira como as diferenças lado a lado são mostradas também pode variar entre os pacotes/arquivos.
Então, pensei que todo o propósito de um sistema de gerenciamento de pacotes é criar uma maneira consistente de instalar e desinstalar programas. Simples de gerenciar para o usuário.
O que deu errado aqui; por que isso é tão horrível em sua UI/UX? Existe algo que um usuário possa fazer para alterar/modificar o apt, pelo menos
- 'fazer uma mesclagem de 3 vias' está disponível
- Os novos arquivos são sempre renomeados/colocados de forma consistente?
Ter que reler e descobrir exatamente o que fazer com cada arquivo de configuração manualmente por causa de 1.000 pequenas variações de fazer a mesma coisa quando se resume ao mesmo procedimento mecânico é doloroso.
Para ilustrar o que quero dizer, aqui estão dois de uma atualização;
Configuration file '/etc/ssh/ssh_config'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
A new version (/tmp/tmp.3RoEfdEm3M) of configuration file /etc/ssh/sshd_config is available, but the version installed currently has been locally modified.
What do you want to do about modified configuration file sshd_config?
install the package maintainer's version
keep the local version currently installed
show the differences between the versions
show a side-by-side difference between the versions
show a 3-way difference between available versions
do a 3-way merge between available versions
start a new shell to examine the situation
Essas opções na segunda variante? Eles nem sempre estão lá nessa ordem.
Parece quase que isso foi feito apenas para te enganar.
Vou abordar as preocupações "voltadas para o usuário" em sua pergunta primeiro:
Isso não pode ser controlado pelos usuários, depende de como o pacote gerencia seus arquivos de configuração (veja abaixo).
Não, mas isso não deveria importar na prática. Em particular, os arquivos temporários mostrados por exemplo em seu segundo exemplo (o
sshd_config
único) são realmente arquivos temporários: eles são uma variante do arquivo de configuração disponibilizado para que as ferramentas de comparação etc. possam encontrar os dados que precisam comparar. (A experiência do usuário pode ser melhorada aqui não mostrando o nome do arquivo temporário por padrão e exibindo-o apenas se o usuário iniciar um shell “para examinar a situação”.)Quanto ao motivo disso acontecer, no Debian especificamente, é porque os arquivos de configuração podem ser manipulados de várias maneiras.
O gerenciador de pacotes,
dpkg
, fornece seu próprio gerenciamento de arquivos de configuração, como você espera. Isso é o que produz a primeira variante em seu exemplo (assh_config
atualização). Ele tem apenas duas informações para trabalhar: o arquivo de configuração como ele existe atualmente no disco e o novo arquivo de configuração enviado no pacote que está tentando instalar. Como resultado, ele não pode oferecer fusões de três vias. Para os mantenedores de pacotes, é muito simples de usar (na verdade, na maioria dos casos, não requer nenhum trabalho).dpkg
A manipulação do arquivo de configuração do 's produz nomes de arquivo consistentes após o fato: arquivos terminando em.dpkg-dist
e.dpkg-old
dependendo se o usuário manteve o arquivo existente (nesse caso, o novo arquivo é mantido para referência posterior, com o.dpkg-dist
extensão) ou instalou o novo (nesse caso, o arquivo antigo é mantido com a.dpkg-old
extensão).Para melhorar esta situação, a
ucf
ferramenta foi desenvolvida. Ele armazena a versão original dos arquivos de configuração, e é por isso que pode fornecer comparações e mesclagens de três vias. No entanto, requer algum trabalho dos mantenedores de pacotes, e é por isso que muitos pacotes não o utilizam. Além disso, o suporte para mesclagens de três vias é opcional. Você pode veropenssh-server
aucf
integração aqui .Além de tudo isso, existe
debconf
o sistema de gerenciamento de configuração Debian. Isto é o que os pacotes que requerem interação durante a instalação devem usar , mas, novamente, isso requer trabalho dos mantenedores de pacotes, então embora agora seja muito comum, ainda existem algumas exceções (incluindo pacotes muito antigos que não foram atualizados para usardebconf
).Claro, alguns mantenedores não gostam de nenhum dos itens acima, ou desenvolveram sua própria solução antes que alguns dos itens acima estivessem disponíveis, então alguns pacotes fazem suas próprias coisas.
Joey Hess escreveu sobre seu envolvimento no conjunto de caixas VA Linux do Debian de 1999 , o que fornece algum contexto em torno da criação
debconf
e reformulação da configuração do pacote.Antes de fazer qualquer atualização, primeiro instale o
distro-info
, caso contrário, procurar nomes de versões anteriores na CLI é complicado sem acesso a um navegador da web.Os comandos:
Em seguida, edite ou, se a mesclagem funcionou:
mv config.file.merged config.file
são uma maneira de fazer a mesma coisa que o debconf/ucf faz manualmente.
Isso apenas deixa os pacotes que não informam aos usuários onde eles deixaram seus arquivos de configuração antigos/novos. Para baixar um arquivo de configuração ausente de uma versão mais antiga do pacote, no meio de um processo de atualização, você pode instalar um sistema totalmente separado e instalar o pacote nele. Ou, você pode baixá-lo manualmente através de um navegador, ftp para a máquina Linux. Mas, se tiver que ser feito na linha de comando da máquina de atualização, as coisas ficam um pouco complicadas.
Isto é o que eu tenho até agora. Ainda há uma coisa não implementada:
GETPACKAGERELEASEVER
--> qual versão de um pacote faz parte do 'buster'? Como faço para imprimir isso? Além disso, como saber se é 'main' ou 'contrib'?(Pergunta relacionada para esta parte; Como faço para verificar a versão do pacote para uma determinada versão de distribuição do cli? )