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

Muitas pessoas comparam a instalação de software com apt-get para rpm -i e, portanto, diga DEB melhor. No entanto, isso não tem nada a ver com o formato do arquivo DEB. A comparação real é dpkg vs rpm e 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 -i e rpm -i não tem como descobrir como instalar dependências, exceto se forem especificadas na linha de comando.

Além dessas ferramentas, há um 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 muito tempo, apt-get foi superior no processamento da enorme quantidade de metadados muito rápido, enquanto yum levaria anos para fazê-lo. O RPM também sofria com sites como o rpmfind, onde você encontraria mais de 10 pacotes incompatíveis para diferentes distribuições. Apt ocultou completamente esse problema nos pacotes DEB porque todos os pacotes foram instalados a partir da mesma fonte.

Na minha opinião, zypper realmente reduziu a diferença para apt e não há razão para ter vergonha 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 em mãos 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-divert possibilita que seu próprio arquivo substitua o que vem de um pacote. Pode ser um salva-vidas quando você tem um programa que procura um arquivo em /usr ou /lib e não aceita /usr/local para uma resposta. A ideia 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 padrão (ar, tar, gzip) para que você possa inspecionar, e em um beliscão Tweak) os 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.) em vez 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, entre outros:

• 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 de fato "totalmente concluídos" de a perspectiva de um novato.

Tamanho da comunidade, participação e riqueza de 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 for o caso, preciso baixar o código-fonte e construir a partir dele. Quando 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 PPAs 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 existiam nos repositórios do RedHat.

Quando o RedHat era uma distribuição (antes dos dias do RHEL, Fedora e Fedora Core), as pessoas às vezes se encontravam no "RPM Hell" ou "dependency 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 uma população 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.

Os 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 a web servidor, esse documento é bastante antigo: Última modificação: dom, 15 de outubro de 2000 , portanto, essa pode não ser a melhor referência.)

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, é realmente bom quando se trata de empacotar rpms para várias plataformas, como openSUSE, SLE, RHEL, centos, Fedora, mandriva, etc.

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

1. Arquivos deb são basicamente apenas arquivos ar que contêm dois tarballs compactados
2. Os pacotes deb e o sistema dpkg armazenam seus scripts de mantenedor como arquivos separados
3. dpkg e rpm executam os scripts do mantenedor em uma ordem diferente durante as atualizações.

Juntas, essas diferenças tornaram muito mais fácil para eu corrigir problemas causados ​​por pacotes defeituosos e fazer com que os pacotes se comportem da maneira que eu preciso, em sistemas baseados em deb do que em Sistemas baseados em rpm, ambos como administrador do sistema e como empacotador.

Por causa do nº 1, se eu precisar alterar um arquivo deb, posso abri-lo trivialmente, fazer as alterações desejadas e reembalá-lo, sando 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 que já está instalado, posso corrigi-lo trivialmente, sando ferramentas padrão existentes em qualquer sistema.

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

Isso significa que a área de superfície por violar o "princípio da capacidade de recuperação" é menor nos pacotes deb: 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 manipulação e conhecimento específicos do pacote é pequena - é acessível a mais pessoas e leva menos tempo e esforço, com arquivos deb.

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.

Vá pesquisar no Google por

1. pacotes duplicados rpm
2. pacotes duplicados do dpkg

Leia as páginas que retornam. É muito revelador que você pode ter um banco de dados RPM desarrumado com pacotes duplicados, enquanto esse caso não ocorre com o dpkg.