Por que os nomes dos pacotes contêm números de versão?

15

Enquanto trabalhava com o Ubuntu e outras distribuições baseadas no Debian, notei que os pacotes nos repositórios de software geralmente contêm o número da versão principal.

Por exemplo,

  • Apache: apache2
  • Tomcat: tomcat7
  • PHP: php5
  • Vinho: wine1.4
  • MySQL: mysql-server-5.5

Percebo, no entanto, que não há apache1pacote disponível e semelhante para o resto. Se o nome do pacote mudar com as atualizações do software, isso não atrapalha um dos principais objetivos do gerenciamento de pacotes (atualizações fáceis)?

Se o Apache 3 for lançado amanhã, vou ter que instalar o apache3pacote manualmente se quiser atualizar? `

Tom Marthenal
fonte

Respostas:

26

Os pacotes são nomeados assim onde existe (ou houve) a necessidade de facilitar a transição entre duas versões principais de um pacote, e o tempo necessário para fazê-lo deve ser longo. Durante o período de transição, as versões nova e antiga são mantidas disponíveis, com o entendimento de que, em algum momento futuro, as versões mais antigas serão descontinuadas.

Às vezes, o período de transição está acontecendo durante a versão do sistema que você está usando no momento. Para alguns pacotes, isso acontece com bastante frequência, e você pode esperar ver versões de pacotes de transição em cada nova versão do sistema. As ferramentas de desenvolvimento de software geralmente se enquadram nessa categoria, pois a atualização para novas ferramentas no mesmo horário das versões do sistema pode não ser prática. A dependência da minha empresa em versões específicas do GCC, Autoconf e Perl pode estar em um ciclo de 5 anos, enquanto meu sistema operacional pode estar em um ciclo de atualização de 3 anos. Portanto, facilita a adoção de novos sistemas operacionais se incluir minhas versões mais antigas de alguns pacotes, além do que estava atual no momento em que o novo sistema operacional estava sendo desenvolvido.

Outras vezes, essas grandes mudanças de versão ocorreram há muito tempo, no passado, e agora todos estão na versão atual. Este é o caso do Apache, por exemplo. Do ponto de vista da compatibilidade, a mudança de 1,3 para 2,0 foi muito maior do que qualquer outra versão da versão 2.x. Assim, quando todos saíram da versão 1.3, não havia mais necessidade de continuar oferecendo várias versões do Apache em uma determinada versão do sistema operacional. Porém, depois que todos usarem o apache2pacote, não haverá um argumento muito bom para renomeá-lo novamente apache. Isso causaria um aborrecimento desnecessário na atualização. Além disso, onde havia uma necessidade percebida no passado de fornecer duas versões paralelas temporariamente, a necessidade provavelmente se repetirá no futuro.

Essa prática de nomeação de pacotes geralmente acontece apenas com bibliotecas ou pacotes principais importantes. Para pacotes mais periféricos, é esperado que você apenas atualize para o que estiver atual no momento.

As bibliotecas são tratadas dessa maneira com mais frequência do que os aplicativos porque, por natureza, outros pacotes dependem delas. Quanto mais popular é uma biblioteca, mais impraticável é exigir que todos os outros pacotes dependentes sejam reconstruídos e vinculados novamente a ela puramente, para que a biblioteca possa ser atualizada passo a passo para uma nova versão principal sem esse período de transição.

Freqüentemente, quando um aplicativo está sendo tratado dessa maneira, é porque ele contém um elemento da biblioteca. Por exemplo, o Apache não é apenas um servidor da Web, ele também fornece uma API de desenvolvimento para os plugins. ( mod_fooe tal.) Se alguém tiver um antigo mod_somethingvinculado ao ABI do plug-in do Apache 1.3 e não o atualizou para usar a API 2.0 mais recente, é conveniente se o seu sistema operacional continuar oferecendo o antigo Apache 1.3 até que todos os criadores do plug-in tenham a chance para atualizar seus plugins.

Warren Young
fonte
3

Pelo que vi, as razões para isso são:

  • Ajude a migração nas principais versões de pacotes: quando o PHP 5 foi lançado, talvez fosse necessário ter uma instalação do PHP 4. Isso permite escolher entre as versões (pelo menos até a versão mais antiga ficar obsoleta).

  • Continue fornecendo atualizações para uma versão mais antiga de um software (por exemplo, após o lançamento do Apache 3, pode ser necessário corrigir o Apache 2) sem atualizá-lo para uma versão principal mais recente.

Por exemplo, o kernel do Linux possui (até hoje) as versões estáveis 3.5, 3.4.7, 3.2.24, 2.6.35.13 etc .... Se você estiver executando o 2.6.35 em um sistema e desejar mantê-lo atualizado, Até o momento, mas não atualizando este kernel, você pode instalar o pacote adequado.

Renan
fonte