Pacotes são nomeados assim, onde há (ou foi) uma necessidade de facilitar a transição entre duas versões principais de um pacote, e o tempo necessário para isso é esperado para ser longo. Durante o período de transição, tanto as versões novas quanto as antigas 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 o lançamento do sistema que você está usando atualmente. Para alguns pacotes, isso acontece o suficiente para que você espere ver versões de pacotes transitórias em todos os novos lançamentos do sistema. As ferramentas de desenvolvimento de software geralmente se enquadram nessa categoria, já que a atualização para novas ferramentas no mesmo cronograma das versões do sistema pode não ser prática. A dependência de 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. Assim, fica mais fácil para mim adotar novos sistemas operacionais se incluir minhas versões mais antigas de alguns pacotes, além do que estava em uso no momento em que o novo sistema operacional estava sendo desenvolvido.
Outras vezes, essas mudanças importantes ocorreram há muito tempo, no passado, e agora todos estão na versão atual. Este é o caso do Apache, por exemplo. A mudança de 1.3 para 2.0 foi um negócio muito maior do ponto de vista de compatibilidade do que qualquer outra versão 2.x, portanto, quando todos estavam fora de 1.3, não era mais necessário oferecer várias versões do Apache dentro de uma versão do sistema operacional. Mas, uma vez que você tenha todos usando o pacote apache2 , não há um argumento muito bom para renomeá-lo de volta para apenas apache . Isso causaria um aborrecimento de atualização desnecessário. Além disso, onde havia uma necessidade percebida no passado de fornecer temporariamente duas versões paralelas, a necessidade provavelmente voltará a ocorrer no futuro.
Essa prática de nomeação de pacotes geralmente ocorre apenas com bibliotecas ou pacotes principais importantes. Para pacotes mais periféricos, espera-se que você atualize para o que estiver atual no momento.
As bibliotecas são mais comumente tratadas dessa maneira do que as aplicações porque, por sua natureza, outros pacotes dependem delas. Quanto mais popular é uma biblioteca, mais impraticável é exigir que todos os outros pacotes, dependendo dela, sejam reconstruídos e vinculados a ela puramente para que a biblioteca possa ser atualizada para uma nova versão principal sem esse período de transição.
Muitas vezes, quando um aplicativo está sendo tratado dessa maneira, é porque ele contém um elemento de biblioteca. Por exemplo, o Apache não é apenas um servidor web, ele também fornece uma API de desenvolvimento para os plugins. ( mod_foo e tal). Se alguém tiver um antigo mod_something vinculado ao plug-in do Apache 1.3 ABI e não tiver feito upgrade dele para usar a API 2.0 mais recente, será conveniente se seu SO continuar oferecendo o antigo Apache 1.3 até que todos os criadores de plugins têm a chance de atualizar seus plugins.