Por que os desenvolvedores do Linux não podem criar um formato de empacotamento universal?

As seleções de formato de pacote binário do fornecedor parecem ser determinadas por uma forma da Lei de Murphy: todas as distros que você não usa têm pacotes. (Corralário: não existe distribuição que satisfaça as dependências de distribuição da sua pilha de software).

É uma questão de política ou algo mais profundo que não vimos o surgimento de um formato de pacote "construa uma vez, execute em qualquer lugar"?

Parece apropriado citar Joel Spolsky sobre este:

(A propósito, para aqueles que seguem o mundo arcano, mas politicamente carregado, dos formatos de feed de distribuição de blogs, é possível ver o mesmo acontecendo por lá. O RSS ficou fragmentado com várias versões diferentes, especificações imprecisas e muita luta política, e a tentativa de limpar tudo criando outro formato chamado Atom resultou em várias versões diferentes do RSS, mais uma versão do Atom, especificações imprecisas e muita luta política.Quando você tenta unificar duas forças opostas criando uma terceira alternativa, você acaba com três forças opostas. Você não unificou nada e realmente não consertou nada.)

(enfase adicionada)

Você possui (pelo menos) dois sistemas de empacotamento para Linux. Isso é realmente uma coisa boa. Um único sistema simplesmente criará um terceiro sistema.

Existem muitas razões para isso, e um pouco de história é para colocar as coisas em perspectiva.

Lembre-se de que, quando falamos em "Linux", geralmente nos referimos a uma das muitas distribuições Linux diferentes . "Linux" é na verdade apenas um kernel do sistema operacional.

O objetivo original do Linux era criar um sistema baseado em Unix que rodasse em PCs (inicialmente o 386). O primeiro passo foi criar o próprio kernel. Enquanto Linus Torvalds estava trabalhando no kernel, Richard Stallman estava trabalhando em seu próprio sistema Free Unix, sob o projeto GNU (GNU's Not Unix) . Para encurtar a história, os dois convergiram um pouco porque o GNU tinha os utilitários associados (compilador C / biblioteca / ferramentas de construção, shell, editores de texto etc.), mas não tinha núcleo para executá-lo, e o Linux tinha o núcleo, mas não tinha utilitários para correr em cima dele para torná-lo útil para as massas.

Essa convergência passou a ser conhecida oficialmente como GNU / Linux. Você verá que muitas distros ainda se referem a si mesmas como distribuições GNU / Linux.

Devido à natureza livre e aberta do GNU / Linux, qualquer um poderia buscá-lo e criar um sistema agrupado para seus gostos específicos. O resultado foi que muitos fluxos diferentes de métodos de configuração variados foram usados ​​para criar esses sistemas, que tiveram o efeito colateral de criar quase tantos sistemas de gerenciamento de pacotes diferentes para se encaixarem em cada um.

Cada sistema completo diferente tinha seus próprios seguidores fortes que os mantiveram ao longo dos anos, resultando no que temos hoje: um punhado de sistemas de gerenciamento de pacotes amplamente usados, profundamente enraizados e estáveis, como RPM , APT / dpkg e Portage do Gentoo .

Existem projetos, como o Autopackage , que estão tentando resolver o problema, mas a evolução contínua dos vários sistemas de gerenciamento de pacotes suportados significa que existem muitos objetivos móveis a serem seguidos.

O que alguns fornecedores de software acabam fazendo é agrupar os binários e cópias específicos das dependências necessárias em um pacote grande que funcionará em sistemas específicos.

Ter o mesmo formato de pacote não ajudaria de qualquer maneira. Você simplesmente não pode usar o mesmo pacote em outras distribuições. Você nem sempre pode usá-lo na versão diferente da mesma distribuição. E até a construção do pacote pode ter os mesmos problemas.

Para instalar um pacote, você precisa atender às dependências que são formadas durante a criação do pacote. Para compilar um pacote, você precisa atender às dependências de compilação. E essas coisas mudam. Para poder implementar as alterações, é mais fácil oferecer suporte apenas aos pacotes que você pode modificar para funcionar após as alterações.

Se todas as dependências fossem iguais, não haveria uma distribuição diferente ou uma versão diferente da mesma distribuição.

Há um pouco de "síndrome não inventada aqui", eu acho. O sistema de empacotamento do Debian é anterior ao RedHat, e ainda é superior em muitos aspectos, mas você nunca verá o RedHat alternando. Em vez disso, você vê muitas pessoas usando o "apt-rpm" que tenta oferecer a você algumas das vantagens do apt com arquivos rpm.

Basta ir para .deb :-)

Havia vários formatos provisórios, como instalação zero e pacote automático . Infelizmente, ninguém ganhou força.

Acho que Cletus, Wayne e Iny responderam muito bem a isso. Eu gostaria de acrescentar que realmente, não é um grande negócio. Eu trabalho em um ambiente misto, onde temos o Gentoo (portage), o SUSE (rpm / zypper) e o OpenBSD (pacotes e portas). Instalar pacotes em qualquer um deles não é difícil, e eu realmente não me importo com o formato que eles estão usando.

Da perspectiva do software de empacotamento, também não é abertamente difícil. Seja o Gentoo, uma distribuição baseada em RPM ou uma distribuição baseada em deb, tudo se resume a ter receitas para construir o software e adicionar alguns metadados. Desde que o sistema de compilação do que você está tentando empacotar não seja totalmente insano, geralmente é preciso pouco mais do que escrever um script de shell glorificado para criar um pacote.

Bem, sempre existem binários estaticamente compilados em bolas de alcatrão .... ;-)

Não há definição de uma interface binária padrão para o "Linux", pois é apenas um kernel. As probabilidades incluem que sua pilha de software precisará interagir com mais do que apenas seu kernel, apresentando um desafio particular de manter uma ABI padrão entre centenas de árvores de origem diferentes.

No tópico de boas ferramentas de empacotamento, eu prefiro o Debian GNU / Linux por seu excelente formato de empacotamento binário. Atendeu 90% das minhas necessidades de ferramentas e aplicativos padrão. Os 10% restantes são criados a partir da origem devido à inclusão de componentes não livres ou dependências de bibliotecas compartilhadas com bugs. Quando esses aplicativos precisam ser implantados, eu construo binários personalizados para os clusters de produção.

Para obter uma compilação única, execute o formato de pacote em qualquer lugar sem forçar todos a usar a mesma distribuição, são necessários alguns recursos importantes:

• Nomeação de pacotes globalmente exclusiva, para que duas pessoas / distribuições não possam criar pacotes diferentes com o mesmo nome de forma independente.

• A capacidade de instalar em paralelo versões diferentes de bibliotecas quando os pacotes têm requisitos conflitantes. Uma distribuição pode decidir qual versão de cada biblioteca usar e forçar todos os pacotes a usarem essa versão. Um sistema que funciona em distribuições deve ser mais flexível.

A Instalação Zero fornece esses dois recursos:

• Os nomes são URIs (por exemplo, http://rox.sourceforge.net/2005/interfaces/ROX-Filer ). Somente o proprietário de um domínio pode criar pacotes dentro desse espaço para nome por padrão.

• Cada versão de cada pacote entra em seu próprio diretório. Cada aplicativo vê apenas as bibliotecas de que precisa, com as versões compatíveis.

Por exemplo, o aplicativo Edit depende de Python <3 como este:

<command name="run" path="Edit/AppRun">
  <runner interface="http://repo.roscidus.com/python/python">
    <version before="3"/>
  </runner>
</command>

Consulte também: http://www.osnews.com/story/16956/Decentralised-Installation-Systems

[Nota: eu sou desenvolvedor 0install]