Quais são as vantagens / desvantagens do deb vs. rpm?

Question

Por alguma razão, eu sempre usei distribuições baseadas em RPM (Fedora, Centos e atualmente openSUSE). Muitas vezes ouvi dizer que deb é melhor do que rpm, mas quando perguntado por que, nunca foi capaz de obter uma resposta coerente (geralmente obter algumas reclamações zelosas e quantidades copiosas de cuspe em vez disso).

Eu 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 em relação ao outro?

    

Answer 1

A principal diferença para um mantenedor de pacotes (acho que seria o 'desenvolvedor' na linguagem Debian) é a maneira como os meta-dados do pacote e os scripts que os acompanham se encaixam.

No mundo do RPM, todos os seus pacotes (os RPMs que você mantém) estão localizados em algo como ~/rpmbuild . Abaixo, há o diretório SPEC para seus arquivos spec, um diretório SOURCES para tarballs de origem, RPMS e SRPMS diretórios para colocar os RPMs e SRPMs recém-criados, e algumas outras coisas que não são relevantes agora .

Tudo que tem a ver com a forma como o RPM será criado está no arquivo de especificações: quais correções serão aplicadas, possíveis pré e pós-scripts, meta-dados, changelog, tudo . Todos os tarballs de origem e todas as correções de todos os seus pacotes estão em SOURCES.

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

Para os RPMs é importante usar o mesmo tarball exato que o release do projeto upstream, até o timestamp. Geralmente, não há exceções a essa regra. Pacotes Debian também requerem o mesmo tarball que o upstream, embora a política Debian exija que alguns tarballs sejam reempacotados (obrigado, Umang).

Os pacotes Debian adotam uma abordagem diferente. (Perdoe qualquer erro aqui: Eu sou muito menos experiente com o deb que estou com o RPM.) Os arquivos de desenvolvimento dos pacotes Debian estão contidos em um diretório por pacote.

O que eu gosto de pensar sobre essa 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 é (ainda) o upstream. No mundo do RPM (pelo menos entre os derivados da Red Hat) isso é desaprovado. Veja "Projeto Fedora: Ficar perto dos projetos de 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 - simple - de um programa Python setuptool'ed é tão simples quanto criar alguns arquivos de metadados e executar debuild . Dito isto, o arquivo spec para tal pacote no formato RPM seria bem curto e no mundo do RPM, também, há muita coisa que é automatizada atualmente.

    

Answer 2

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

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

No topo dessas ferramentas, há o gerenciamento de repositório na forma de apt-... ou zypper / yum . Essas ferramentas baixam 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 tempo para isso. O RPM também sofria de sites como o rpmfind, onde você encontraria 10 + pacotes incompatíveis para diferentes distribuições. Apt ocultou completamente este problema para pacotes DEB porque todos os pacotes foram instalados a partir da mesma fonte.

Na minha opinião, zypper realmente diminuiu a diferença para apt e não há motivo para se envergonhar de usar uma distribuição baseada em RPM atualmente. É tão bom, senão mais fácil de usar, com o serviço de compilação do openSUSE disponível para um enorme índice de pacote compatível.

    

Answer 3

Do ponto de vista de um administrador de sistemas, encontrei algumas pequenas diferenças, principalmente no conjunto de ferramentas dpkg / rpm e não no formato de 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 por um arquivo em /usr ou /lib e não aceita /usr/local para uma resposta. A idéia foi proposta, mas, até onde posso dizer, não 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 sobrescrevia os arquivos de configuração modificados e movia minhas personalizações para *.rpmsave (IIRC). Isso tornou o meu sistema não inicializável pelo menos uma vez. O Dpkg me pergunta o que fazer, mantendo minhas customizações como padrão.

• Um pacote binário rpm pode declarar dependências em arquivos em vez de pacotes, o que permite um controle mais preciso do que um pacote deb.

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

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

• Um pacote deb usa formatos padrão ( ar , tar , gzip ) para que você possa inspecionar e, com facilidade, ajustar os pacotes deb facilmente. Pacotes de RPM não são tão amigáveis.

Answer 4

RPM:

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

DEB:

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

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

    

Answer 5

Acho que o preconceito não vem do formato do pacote, mas das inconsistências que existiam nos repositórios do RedHat.

De volta quando RedHat era uma distribuição (antes dos dias do RHEL, Fedora e Fedora Core), as pessoas às vezes se encontravam em "RPM Hell" ou "dependency Hell". Isso ocorria quando um repositório acabava com um pacote que tinha dependências (várias camadas profundas, 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 um desgosto para os sistemas RPM entre uma população de usuários de Linux que foram queimados pelo problema.

    

Answer 6

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

• A filosofia do design da embalagem original 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 "funcione" assim que for instalado. Isso significa que, durante a instalação, espera-se que os pacotes cuidem de tudo o que for necessário para realmente executar bem, incluindo, mas não se limitando a:

• configurando tarefas agendadas 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 corretos para bibliotecas (.so) para compatibilidade com versões anteriores
• suporte limpo para binários de vários arcos (32 e 64 bits) na mesma máquina e assim por diante.

No mundo das rpm - reconhecidamente esta era a situação há vários anos, e pode ter melhorado desde então - eu me encontrei tendo que executar etapas adicionais (por exemplo, chkconfig, permitindo tarefas cron) para realmente fazer os pacotes realmente funcionarem. Isso pode ser bom para administradores de sistemas ou pessoas com conhecimento sobre o Unix, mas isso faz com que experiências de novatos sejam prejudicadas. Note que não é que o próprio formato do pacote RPM impeça que isso aconteça, é apenas que muitos pacotes não são de fato "totalmente feitos" da perspectiva de um novato.

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

Como a comunidade do ubuntu / debian / mint / ... é maior, mais pessoas estão envolvidas no empacotamento e no teste de software. Eu achei a riqueza e a qualidade dos repositórios superiores. No ubuntu, raramente preciso fazer o download da fonte e compilar a partir dela. Quando mudei da Red Hat para o Ubuntu em casa, o repo típico do RHEL tinha ~ 3000 pacotes, enquanto, ao mesmo tempo, ubuntu + universe + multiverse, todos disponíveis diretamente de qualquer espelho da Canonical, tinham ~ 30.000 pacotes (aproximadamente 10x). A maioria dos pacotes que eu estava procurando no formato RPM, não estava prontamente acessível por meio de pesquisa simples e clique no gerenciador de pacotes. Eles precisavam alternar para repositórios alternativos, pesquisar o 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 acertei o fenômeno do "inferno da dependência", como descrito acima por Shawn J. Goff.

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

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

Eu nunca tive que me comprometer com versões mais antigas de pacotes que eu me importava, mesmo quando eles não eram mantidos por desenvolvedores oficiais (canônicos). Eu nunca tive que deixar meu gerenciador de pacotes GUI amigável para realizar uma busca conveniente por palavra-chave, para encontrar e instalar qualquer pacote que eu quisesse. Além disso, algumas vezes eu instalei pacotes debian (não canônicos) no Ubuntu e eles funcionaram muito bem, apesar de essa compatibilidade não ser oficialmente garantida.

Note que isto não tem a intenção de iniciar uma guerra de chamas, é apenas compartilhar minha experiência, tendo usado os dois mundos paralelamente por vários anos (trabalho x lar).

    

Answer 7

Existe também a diferença "filosófica" onde nos pacotes Debian você pode fazer perguntas e assim, bloquear o processo de instalação. O lado ruim disso é que alguns pacotes bloquearão seus upgrades até que você responda. O lado bom disto é, também como uma diferença filosófica, em sistemas baseados em Debian, quando um pacote é instalado, é configurado (não sempre como você gostaria) e rodando. Não em sistemas baseados em Redhat, onde você precisa criar / copiar a partir de / usr / share / doc / * um arquivo de configuração padrão / template.

    

Answer 8

Uma coisa que eu gosto sobre RPMs é a (recente?) adição de delta RPMs. Isso permite uma atualização mais fácil, reduzindo a largura de banda necessária.

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

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

    

Answer 9

O openSUSE Build Service (OBS) e o zypper são algumas das razões pelas quais eu prefiro o RPM sobre o deb do ponto de vista do empacotador e do usuário. Zypper já percorreu um longo caminho e é muito rápido. O OBS, embora possa lidar com debs, é muito bom quando se trata de empacotamento de rpms para várias plataformas, como openSUSE, SLE, RHEL, centos, fedora, mandriva, etc.

    

Answer 10

Os pacotes Debian podem incluir um tamanho instalado , mas Eu 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 invocado por causa de ações que podem ser tomadas nos scripts de pré / pós-instalação.

Aqui está uma boa referência para comparação de alguns recursos específicos que estão disponíveis para cada formato de embalagem específico: link (de acordo com o servidor web, esse documento é bem antigo: Last-Modified: Sun, 15 out 2000 , então esta pode não ser a melhor referência.)

    

Answer 11

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

    

Answer 12

Pesquise no Google por

1. pacotes duplicados de rpm
2. pacotes duplicados do dpkg

Leia as páginas que voltam. É importante dizer que você pode ter um banco de dados RPM confuso com pacotes duplicados enquanto nenhum caso desse tipo acontece com o dpkg.