Os formatos de pacote deb e rpm foram desenvolvidos separadamente ao mesmo tempo para resolver os mesmos problemas básicos. A maioria dos servidores executa o RHEL apenas porque, historicamente, tem sido a distribuição mais popular e adotou novas tecnologias, o que permitiu que as pessoas que eram pacientes apenas acampassem em uma distro que conheciam. Eu diria que, se você estiver planejando uma implantação corporativa, vá com o RHEL / CentOS, pois será mais fácil localizar e capacitar pessoas que tenham experiência com essa distro específica (não por causa do gerenciador de pacotes). A Canonical fornece edições corporativas do Ubuntu, mas sua infra-estrutura de suporte (como empresa) não é tão bem desenvolvida quanto a SuSE ou Red Hat e ainda é uma qualificação de nicho no Linux corporativo.
Os formatos em si são diferentes porque cada um tentava resolver o problema sem consultar o outro, e o que existe em um existe no outro. É como países com direção do lado esquerdo e aqueles com direção no lado direito. Contanto que você aplique a regra de forma consistente, não há nada de errado com qualquer um deles. Há muito pouco esforço para unificar as pessoas em qualquer das soluções pelo mesmo motivo: não é realmente um problema. As duas soluções são características competitivas e não é como se houvesse uma garantia de ampla compatibilidade ABI entre distribuições baseadas em RPM e distribuições baseadas em dpkg (o que significa que não há muito a ganhar com o software gerenciador de pacotes compartilhado).
Os administradores podem ter preferências pessoais sobre o quanto preferem coisas como apt-get versus yum , mas isso é tudo, uma preferência pessoal.
No que diz respeito aos pacotes envolvidos, você quer se concentrar nos estilos "Enterprise" e "Community" de desenvolvimento de pacotes, mas ainda não no formato de arquivo.
As embalagens comunitárias normalmente têm requisitos de QA muito frouxos e a distro comunitária tem um strong incentivo para fornecer tudo sob o sol para que todos possam encontrar os pacotes de que precisam. Pacotes corporativos garantem certas garantias envolvendo compatibilidade ABI dentro de versões principais, seleção de pacotes e a introdução de novos recursos, tudo para estabilidade.
-
A garantia da ABI - A Interface Binária do Aplicativo permite que você execute atualizações do sistema e só tenha que reiniciar programas individuais vinculados a qualquer coisa que tenha sido substituída (bibliotecas, executáveis, etc.). Se o upstream corrigir algo relevante para uma versão enviada a você, seu provedor de distro EL deve sair e encontrar uma maneira de retroceder a correção para a versão que está enviando de uma maneira que não interrompa mais nada. Isso também ajuda a própria plataforma a obter a certificação de produto para produtos ISV que você pode precisar executar.
-
A seleção restrita de pacotes permite que a empresa forneça os pacotes de forma mais abrangente ao software de controle de qualidade que você pode ver ao procurar uma solução para um problema. Isso é diferente de algo como o Fedora, onde o pacote não precisa ser quebrado e parecer útil para alguém antes de ser incluído.
-
Novos recursos, obviamente, introduzem bugs e estão sujeitos a constante mudança e depreciação. Atrasar a adoção de recursos é a maneira da distro de proteger os usuários corporativos desse caos, mas também ajuda a garantir o requisito de compatibilidade ABI.
Provavelmente mais informações do que você queria, mas lá vai você.