Quais são os prós / contras de deb vs. rpm?

Por qualquer motivo, eu sempre usei distribuições baseadas em RPM (Fedora, Centos e atualmente o openSUSE). Muitas vezes ouvi dizer que deb é melhor que rpm, mas, quando perguntado por quê, nunca foi capaz de obter uma resposta coerente (geralmente, obtém algumas zelosas reclamações e copiosas quantidades de saliva).

Entendo que pode haver algumas razões históricas, mas para distribuições modernas usando os dois métodos de embalagem diferentes, alguém pode dar os méritos técnicos (ou outros) de um contra o outro?

A principal diferença para um mantenedor de pacotes (acho que seria 'desenvolvedor' na linguagem Debian) é a maneira como os metadados de pacotes e os scripts que os acompanham se reúnem.

No mundo do RPM, todos os seus pacotes (os RPMs que você mantém) estão localizados em algo parecido ~/rpmbuild. Abaixo, há o SPECdiretório para seus arquivos de especificação, um SOURCESdiretório para tarballs de origem RPMSe SRPMSdiretórios nos quais colocar RPMs e SRPMs recém-criados, e algumas outras coisas que não são relevantes agora.

Tudo o que tem a ver com a criação do RPM está no arquivo de especificações: quais patches serão aplicados, possíveis pré e pós-scripts, metadados, changelog, tudo. Todos os tarballs de origem e todos os patches de todos os seus pacotes estão em SOURCES.

Agora, pessoalmente, eu gosto do fato de que tudo entra no arquivo de especificação e que o arquivo de especificação é uma entidade separada do tarball de origem, mas não estou muito entusiasmado por ter todas as fontes em SOURCES. IMHO, SOURCES fica confuso muito rápido e você tende a perder a noção do que está lá. No entanto, as opiniões são diferentes.

Para RPMs, é importante usar exatamente o mesmo tarball que o projeto upstream libera, até o registro de data e hora. Geralmente, não há exceções a esta regra. Os pacotes Debian também exigem o mesmo tarball que o upstream, embora a política Debian exija que alguns tarballs sejam reembalados (obrigado, Umang).

Pacotes Debian adotam uma abordagem diferente. (Perdoe qualquer erro aqui: eu sou muito menos experiente com os debs do que com os RPMs.) Os arquivos de desenvolvimento dos pacotes Debian estão contidos em um diretório por pacote.

O que eu acho que gosto nessa abordagem é o fato de que tudo está contido em um único diretório.

No mundo Debian, é um pouco mais aceito carregar patches em um pacote que não está (ainda) a montante. No mundo do RPM (pelo menos entre os derivativos da Red Hat), isso é desaprovado. Veja "FedoraProject: Ficando perto de projetos upstream" .

Além disso, o Debian possui uma grande quantidade de scripts que são capazes de automatizar uma grande parte da criação de um pacote. Por exemplo, criar um pacote - simples - de um programa Python configurado como ferramenta, é tão simples quanto criar alguns arquivos de metadados e executá-los debuild. Dito isso, o arquivo de especificação para esse pacote no formato RPM seria bem curto e, no mundo do RPM, também há muitas coisas que são automatizadas atualmente.

Muitas pessoas comparam a instalação de software apt-geta rpm -ie, portanto, dizem DEB melhor. No entanto, isso não tem nada a ver com o formato do arquivo DEB. A comparação real é dpkgvs rpme aptitude/ apt-*vs zypper/ yum.

Do ponto de vista do usuário, não há muita diferença nessas ferramentas. Os formatos RPM e DEB são apenas arquivos compactados, com alguns metadados anexados a eles. Ambos são igualmente arcanos, possuem caminhos de instalação codificados (eca!) E diferem apenas em detalhes sutis. Ambos dpkg -ie rpm -inão têm como descobrir como instalar dependências, exceto se forem especificadas na linha de comando.

No topo dessas ferramentas, há gerenciamento de repositório na forma de apt-...ou zypper/ yum. Essas ferramentas fazem o download de repositórios, rastreiam todos os metadados e automatizam o download de dependências. A instalação final de cada pacote é entregue às ferramentas de baixo nível.

Por um longo tempo, apt-getfoi superior no processamento da enorme quantidade de metadados muito rápido, enquanto yumlevaria séculos para isso. O RPM também sofria com sites como o rpmfind, onde você encontraria mais de 10 pacotes incompatíveis para diferentes distribuições. Aptocultou completamente esse problema nos pacotes DEB porque todos os pacotes foram instalados a partir da mesma fonte.

Na minha opinião, zypperrealmente diminuiu a diferença apte não há razão para se envergonhar de usar uma distribuição baseada em RPM atualmente. É tão bom se não mais fácil de usar com o serviço de compilação openSUSE disponível para obter um enorme índice de pacotes compatíveis.

Do ponto de vista do administrador do sistema, eu encontrei algumas pequenas diferenças, principalmente no conjunto de ferramentas dpkg / rpm, e não no formato do pacote.

• dpkg-diverttorna possível que seu próprio arquivo substitua o arquivo de um pacote. Pode ser um salva-vidas quando você tem um programa que procura um arquivo /usrou /libnão aceita /usr/localuma resposta. A idéia foi proposta, mas até onde sei não foi adotada, em rpm.

• Quando administrei pela última vez sistemas baseados em rpm (o que, reconhecidamente, era anos atrás, talvez a situação tenha melhorado), o rpm sempre substituía os arquivos de configuração modificados e transferia minhas personalizações para *.rpmsave(IIRC). Isso tornou meu sistema não inicializável pelo menos uma vez. O Dpkg me pergunta o que fazer, mantendo minhas personalizações como padrão.

• Um pacote binário rpm pode declarar dependências em arquivos e não em pacotes, o que permite um controle mais refinado do que um pacote deb.

• Você não pode instalar um pacote da versão N rpm em um sistema com a versão N-1 das ferramentas rpm. Isso pode se aplicar ao dpkg também, exceto que o formato não muda com tanta frequência.

• O banco de dados dpkg consiste em arquivos de texto. O banco de dados rpm é binário. Isso torna o banco de dados dpkg fácil de investigar e reparar. Por outro lado, desde que nada dê errado, o rpm pode ser muito mais rápido (instalar uma deb exige a leitura de milhares de arquivos pequenos).

• Um pacote deb usa formatos standard ( ar, tar, gzip) para que você possa inspecionar e em um tweak pitada) pacotes deb facilmente. Pacotes de RPM não são tão amigáveis.

RPM:

• 'Padronizado' (não que não haja uma especificação de deb)
• Usado por muitas distribuições diferentes (mas os pacotes de uma não necessariamente funcionam em outra)
• O IIRC permite dependências em arquivos, não apenas em pacotes

DEB:

• Crescente popularidade
• Permite recomendações e sugestões (possivelmente o RPM mais recente também permita)

Provavelmente a questão mais importante é o gerenciador de pacotes (dpkg vs. yum vs. aptitude etc.) ao invés do formato do pacote (pois ambos são comparáveis).

Como vários respondentes disseram, não é tanto que um determinado formato de pacote seja claramente superior. Tecnicamente, eles podem ser mais ou menos comparáveis. Na minha perspectiva, muitas das diferenças e por que as pessoas preferem uma à outra têm a ver com:

• A filosofia do design original da embalagem e o público-alvo
• O tamanho da comunidade e, por extensão, a qualidade e a riqueza dos repositórios

Filosofia:

No mundo Ubuntu / Debian / Mint / ..., os usuários esperam que o pacote instalado "apenas funcione" depois de instalado. Isso significa que, durante a instalação, espera-se que os pacotes cuidem de tudo o que for necessário para que eles funcionem bem, incluindo, mas não se limitando a:

• configurando tarefas cron necessárias ou opcionais
• configurando alternativas / aliases
• configurando scripts de inicialização / desligamento
• incluindo todos os arquivos de configuração necessários com padrões que fazem sentido
• mantendo versões antigas de bibliotecas e adicionando os links simbólicos com versão correta às bibliotecas (.so) para compatibilidade com versões anteriores
• suporte limpo para binários com vários arcos (32 e 64 bits) na mesma máquina e assim por diante.

No mundo do rpm - é certo que essa era a situação há vários anos e pode ter melhorado desde então - eu tive que executar etapas adicionais (por exemplo, chkconfig, habilitando tarefas cron) para realmente fazer os pacotes realmente funcionarem. Isso pode ser bom para administradores de sistemas ou pessoas que conhecem o Unix, mas faz com que as experiências para iniciantes sofram. Observe que não é que o próprio formato de pacote RPM impeça que isso aconteça, é apenas que muitos pacotes não são "totalmente concluídos" da perspectiva de um novato.

Tamanho, participação e riqueza da comunidade dos repositórios:

Como a comunidade ubuntu / debian / mint / ... é maior, mais pessoas estão envolvidas no empacotamento e teste de software. Eu achei a riqueza e a qualidade dos repositórios superiores. No ubuntu, raramente, se é que preciso, fazer o download do código-fonte e construir a partir dele. Quando eu mudei do Red Hat para o Ubuntu em casa, o repositório RHEL típico tinha ~ 3000 pacotes, enquanto, ao mesmo tempo, o ubuntu + universe + multiverse, todos disponíveis diretamente de qualquer espelho canônico, tinha ~ 30.000 pacotes (aproximadamente 10x). A maioria dos pacotes que eu estava procurando no formato RPM não era facilmente acessível por meio de pesquisa simples e clique no gerenciador de pacotes. Eles precisavam mudar para repositórios alternativos, pesquisar no site do serviço rpmfind etc. Isso, na maioria dos casos, em vez de resolver o problema, interrompeu minha instalação ao não restringir quais dependências podem ou não ser atualizadas corretamente. Eu bati no fenômeno do "inferno da dependência", como descrito acima por Shawn J. Goff.

Em contraste no Ubuntu / Debian, descobri que quase nunca preciso construir a partir do código-fonte. Também por causa de:

• O ciclo de lançamento rápido do Ubuntu (6 meses)
• A existência de CAE totalmente compatíveis que funcionam imediatamente
• Os repositórios de fonte única (todos hospedados pela Canonical) não precisam procurar repositórios alternativos / complementares
• Experiência perfeita do usuário, do clique para executar

Eu nunca tive que me comprometer com versões mais antigas de pacotes que me importavam, mesmo quando elas não eram mantidas por desenvolvedores oficiais (Canonical). Eu nunca tive que sair do meu gerenciador de pacotes GUI amigável favorito para realizar uma pesquisa conveniente por palavra-chave, para encontrar e instalar qualquer pacote que eu desejasse. Além disso, algumas vezes eu instalei pacotes debian (não Canonical) no Ubuntu e eles funcionaram muito bem, apesar dessa compatibilidade não ser oficialmente garantida.

Note que isso não pretende iniciar uma guerra de chamas, é apenas compartilhar minha experiência de ter usado os dois mundos em paralelo por vários anos (trabalho versus casa).

Eu acho que o viés não vem do formato do pacote, mas das inconsistências que costumavam existir nos repositórios do RedHat.

Quando o RedHat era uma distribuição (antes dos dias do RHEL, Fedora e Fedora Core), às vezes as pessoas se encontravam no "RPM Hell" ou na "dependência Hell". Isso ocorreu quando um repositório terminava com um pacote que tinha dependências (várias camadas de profundidade, geralmente) que eram mutuamente exclusivas. Ou surgiria quando dois pacotes diferentes tivessem duas dependências mutuamente exclusivas. Este foi um problema com o estado do repositório, não com o formato do pacote. O "RPM Hell" deixou uma aversão aos sistemas RPM entre algumas populações de usuários de Linux que se queimaram com o problema.

Há também a diferença "filosófica" em que nos pacotes Debian você pode fazer perguntas e, com isso, bloquear o processo de instalação. O lado ruim disso é que alguns pacotes bloquearão suas atualizações até você responder. O lado bom disso é, também como uma diferença filosófica, nos sistemas baseados no Debian, quando um pacote é instalado, ele é configurado (nem sempre como você gostaria) e funcionando. Não nos sistemas baseados no Redhat, onde você precisa criar / copiar de / usr / share / doc / * um arquivo de configuração padrão / modelo.

Uma coisa que eu gosto nos RPMs é a adição (recente?) De RPMs delta. Isso facilita a atualização, reduzindo a largura de banda necessária.

DEBs são arquivos AR padrão (com mais arquivos padrão dentro), RPMs são arquivos binários "proprietários". Pessoalmente, acho que o primeiro é mais conveniente.

Apenas duas coisas que consigo pensar em cima da minha cabeça. Ambos são muito comparáveis. Ambos possuem excelentes ferramentas para embalagem. Eu não acho que haja tantos méritos para um sobre o outro ou vice-versa.

O openSUSE Build Service (OBS) e o zypper são alguns dos motivos pelos quais prefiro o RPM do que o deb do ponto de vista do empacotador e do usuário. O Zypper percorreu um longo caminho e é bastante rápido. O OBS, embora possa lidar com debs, é muito bom quando se trata de empacotar rpms para várias plataformas, como openSUSE, SLE, RHEL, centos, fedora, mandriva, etc.

Pacotes Debian podem incluir um tamanho instalado , mas não acredito que os RPMs tenham um campo equivalente. Ele pode ser calculado com base nos arquivos incluídos no pacote, mas também não pode ser considerado devido a ações que podem ser executadas nos scripts de instalação anterior / posterior.

Aqui está uma boa referência para comparação de alguns recursos específicos disponíveis para cada formato de embalagem específico: http://debian-br.sourceforge.net/txt/alien.htm (de acordo com o servidor da Web, esse documento é bastante antigo : Última modificação: domingo, 15 de outubro de 2000, portanto, essa pode não ser a melhor referência.)

Para pacotes Debian, há um grande conjunto de scripts auxiliares, um manual de políticas consistente e pelo menos uma maneira de fazer quase tudo. As dependências são tratadas muito bem e podem ser definidas com granularidade muito boa. Reconstruir pacotes é muito fácil com os pacotes debian e é bem suportado pelas ferramentas disponíveis.

Nenhuma das outras respostas aborda como as três diferenças fundamentais a seguir têm consequências reais:

1. debarquivos são basicamente ararquivos contendo dois tarballs compactados
2. debpacotes e o dpkgsistema armazenam seus scripts de mantenedor como arquivos separados
3. dpkge rpmexecute os scripts do mantenedor em uma ordem diferente durante as atualizações.

Juntas, essas diferenças tornaram muito mais fácil para mim corrigir problemas causados ​​por pacotes incorretos e fazer com que os pacotes se comportassem da maneira que eu precisava, em debsistemas rpmbaseados em sistemas baseados em sistemas, tanto como administrador do sistema quanto como empacotador .

Por causa do número 1, se eu precisar alterar um debarquivo, posso abri-lo trivialmente, fazer as alterações que desejar e reembalá-lo, usando ferramentas padrão existentes na maioria dos sistemas .

Isso inclui alterar / adicionar / remover quaisquer dependências, arquivos dos pacotes ou scripts do mantenedor ou alterar a versão ou o nome do pacote.

Por causa do nº 2, se houver um problema nos scripts "remover" instalados por um pacote já instalado , eu posso corrigi-lo trivialmente, usando as ferramentas padrão existentes em qualquer sistema .

Por causa do nº 3, posso fazer algumas dessas correções apenas lançando uma nova versão do meu pacote, pois durante a atualização, dpkgexecuta o script "pré-instalação" da nova versão do pacote antes do script "pós-remoção" de a versão antiga.

Isso significa que a área de superfície por violar o "princípio da capacidade de recuperação" é menor nos debpacotes: mais erros em uma versão anterior do pacote podem ser recuperados com uma nova versão.

E como a modificação do pacote é tão fácil - a sobrecarga real de conhecimento e manipulação específica do pacote é pequena - é acessível a mais pessoas e leva menos tempo e esforço, com debarquivos.