AcompanhandoO binário Ubuntu LTS é compatível com Debian?
Eu sei que os pacotes binários Ubuntu e Debian são incompatíveis na maioria das vezes. Eu sei que misturar pacotes de fontes diferentes geralmente é uma má ideia, e as pessoas são alertadas contra isso o tempo todo. Então vamos manter a discussão puramente técnica.
O que exatamente introduzirá incompatibilidade para pacotes de fontes diferentes, quando é claro que as dependências não são o problema?
------ Separação, mais detalhes abaixo ------
Comoo ditado:
sobre compatibilidade binária (https://wiki.ubuntu.com/MarkShuttleworth#What_about_binary_compatibility_between_distributions.3F): Os pacotes Debian provavelmente são construídos com diferentes versões do conjunto de ferramentas, então você pode ter problemas
Por que diferentes versões do conjunto de ferramentas causarão problemas? Como
- Eu sei como extrair o conjunto mínimo de pacotes do Debian sid para o meu Debian estável, e tenho feito isso o tempo todo,
- Eu costumava carregar pacotes de versões mais antigas do Ubuntu/Debian para suas versões mais recentes, ou mesmo
- copiar um único executável do meu Ubuntu/Debian para outra distro, seja RedHat ou mesmo FreeBSD,
enuncateve problema antes. Então, o que exatamente está causando o problema que as pessoas estão dizendo?
É a versão gcc ou kernel? Improvável para mim, já que eles são atualizados o tempo todo ao longo da vida útil dessa versão.
Então é a versão do glibc? Mas será compatível com versões anteriores normalmente e muito provavelmente, certo?
Citando a resposta do meu primeiro link:
Realmente não há garantia ou mesmo implicação de compatibilidade cruzada. Não espere que as comunidades Debian ou Ubuntu lhe dêem muita simpatia se as coisas derem errado. Nesse caso, você estará sozinho. Contanto que você esteja de acordo com isso, sinta-se à vontade para tentar.
Basicamente, vejo avisos contra a prática em todos os lugares, mas ninguém dá mais explicações técnicas. Alguém pode listar os riscos de fazer isso, esses possíveis problemas técnicos, por favor?
Essa resposta vai me ajudar, se eu quiser/precisar misturar pacotes de fontes diferentes, digamos Debian ou Ubuntu, ou dentro da mesma distribuição, mas versões diferentes, (se as dependências não forem o problema), a escolher a abordagem mais segura, para puxar um PPA que tenho certeza que nunca acabará no Debian, no Debian Bullseye que estou usando atualmente.
Responder1
As incompatibilidades binárias e de pacotes são diferentes e valem a pena ser explicadas separadamente.
Incompatibilidade binária
Geralmente é a isso que se refere quando as pessoas falam sobre diferenças no conjunto de ferramentas, etc.Conjunto de ferramentasas próprias incompatibilidades são incomuns, porque o conjunto de ferramentas é, junto com o kernel, uma das áreas onde os desenvolvedores são mais cuidadosos em preservar a compatibilidade com versões anteriores. Como resultado, um binário construído no passado deve continuar em execução, desde que seubinárioas dependências continuam disponíveis; isso se resume a manter as bibliotecas necessárias.
Onde as coisas quebram é na compatibilidade futura: não é possível garantir que um binário construído “no futuro” seja executado. Isso geralmente aparece como símbolos ausentes na biblioteca C (que são detectados precisamente porque os desenvolvedores da biblioteca C tomam muito cuidado para manter a compatibilidade). Pode-se pensar que a biblioteca C não muda muito, portanto, construir um programa com diferentes bibliotecas C não deve alterar os símbolos necessários e deve permanecer compatível. Esse não é o caso, e as funções mudam regularmente de maneiras incompatíveis com versões anteriores; a biblioteca C preservapara tráscompatibilidade, continuando a fornecer versões de funções compatíveis com interfaces anteriores, com um símbolo de versão apropriado. Por exemplo, a versão 2.33 da biblioteca GNU C possui alterações incompatíveis em funções comuns como a statfamília ( fstat/ lstat/ statetc.); um programa construído com uma configuração padrão de 2.33, usando essas funções, exigirá a versão 2.33 da biblioteca C para ser executado.
As bibliotecas relacionadas ao conjunto de ferramentas e a biblioteca C são mantidas de tal maneira que tais incompatibilidades aparecem como alterações de símbolos de biblioteca ou alterações de soname e, portanto, acabam codificadas em dependências de pacote (para software empacotado) ou são capturadas pelo vinculador dinâmico (para binários separados).
Em bibliotecas que não são mantidas com tanto cuidado quanto a biblioteca C, tais incompatibilidades não aparecem imediatamente, elas só aparecem se a combinação defeituosa for testada (e mesmo assim, talvez apenas em certas circunstâncias). Os desenvolvedores de distribuição geralmente testam pacotes apenas no contexto da versão que está sendo desenvolvida, então eles não saberão que o pacote que construíram para o Ubuntu 20.04 é instalado corretamente no Debian 10, mas mata seu esquilo de estimação se você usá-lo entre 1h e 2h CEST de junho 21.
Isso leva muito bem a ...
Incompatibilidade de pacote
Quer isso seja feito conscientemente ou não, os pacotes raramente são construídos no vácuo, eles fazem parte de uma versão de distribuição. Isso começa com a própria fonte do pacote (e mais geralmente, a fonte do projeto): projetos e pacotes são construídos nos sistemas de seus desenvolvedores e, a menos que um grande esforço seja colocado nisso, podem não codificar com precisão suas dependências.
Isso se resume a dependências de pacotes binários e dependências descritas na documentação. Um mantenedor de projeto pode não perceber que seu projeto na configuração atual só funciona porque, digamos, o systemd versão 239 começou a configurar o sistema de uma determinada maneira. Os mantenedores de pacotes também podem não perceber isso, se o lançamento da distribuição em que estão trabalhando já tiver a versão 239 do systemd (tenha em mente que os mantenedores de distribuição geralmente vivem no futuro,ou sejaeles se desenvolvem no que será o próximo lançamento).
Tudo issopoderiaser pego pelos testes, mas quando você começar a misturar e combinar binários de diferentes distribuições e lançamentos, você provavelmente será a primeira pessoa a testar sua combinação exata de pacotes e versões binárias. EqueÉ por isso que isso não é recomendado: a maioria dos usuários deseja usar seus sistemas, e não testá-los.
Claro, e isso se encaixa na sua experiência, em muitos casos tudo simplesmente funciona. Isso também contribui para o preconceito que você percebe: as pessoas tendem a não escrever postagens (ou perguntas, no contexto do Stack Exchange) explicando como instalaram o pacote X da distribuição Y em seu sistema Z, e ele simplesmente funcionou. Portanto, a maior parte do conteúdo que você vê neste domínio são cenários onde as coisasnãofuncionou, ou acabou sendo complicado de montar, ou quebrou alguma outra coisa; e as pessoas estão compreensivelmente relutantes em gastar tempo ajudando alguém a resolver um problema provavelmente único que elas mesmas causaram ao fazer algo que foi explicitamente recomendadocontra.