Eu não acho que existam distribuições que suportem ambos nativamente, mas acontece que há uma em desenvolvimento, Bedrock Linux (obrigado a iMalinowski pela informação). Em outras distribuições, você pode usar ferramentas de conversão, como alienconverter de um formato para outro. Qualquer coisa baseada em software é factível, com tempo e energia suficientes, então seria possível construir tal distribuição (mas dadas as diferenças entre os recursos de .debe .rpmpacotes, bastante difícil).

No entanto, tudo isso provavelmente decorre da ideia de que o suporte a ambos os formatos de pacote tornaria a vida mais simples, porque você poderia instalar pacotes de qualquer lugar (bem, de qualquer lugar fornecendo um .debou .rpm). Filosoficamente, isso é falho. Uma distribuição é um conjunto coerente de pacotes; se você deseja fornecer software para essa distribuição, realmente precisa direcioná-lo especificamente, o que inclui o uso de seu formato de pacote (e mais importante, metadados). Não faz sentido oferecer suporte nativo a vários formatos de pacote.

(No mundo Debian, os pacotes podem funcionar em variantes que não são seu alvo principal, porque a nomenclatura do pacote é bastante homogênea e porque a maioria das distribuições se encaixa em uma árvore de herança. Isso não é verdade no mundo RPM. Em ambos os casos, misturar e combinar é uma má ideia.)

Você deve considerar sua distribuição como uma base para construir o sistema desejado, respeitando as regras e o ecossistema de sua distribuição, sem misturar coisas de outras distribuições. Você precisa de abstrações de alto nível para dar suporte à mistura e correspondência (ou melhor, para fornecer ambientes de distribuição cruzada): o tempo de execução do Steam, Flatpak, etc.

O Bedrock Linux faz isso. Não estou dizendo que fiz isso, ou que é uma boa ideia, mas está sendo feito.

Não, tal monstro não deveria ser construído. Ao contrário, digamos, de um pacote de aplicativos MacOS, que normalmente inclui tudo o que o aplicativo precisa para ser executado no sistema operacional, os pacotes RPM e .deb quase sempre dependem de outros pacotes, como bibliotecas compartilhadas. Os pacotes do Linux listam os outros pacotes que precisam estar presentes e o gerenciador de pacotes ajuda a impor esses requisitos. Além disso, as distribuições do Linux diferem na forma como as coisas são feitas (por exemplo , /etc/network/interfaces.dvs. /etc/sysconfig/network-scripts).

Você não deve nem misturar pacotes de repositórios arbitrários dentro da mesma família de formato de pacote. Ou seja, instalar pacotes SuSE em uma máquina CentOS é apenas pedir problemas, mesmo que ambos usem RPM. Eu nem instalaria pacotes destinados a uma versão diferente do mesmo sistema operacional (por exemplo, pacotes Ubuntu 14.04 em um sistema 16.04), a menos que soubesse exatamente o que estava fazendo.

Portanto, tentar oferecer suporte a RPM e .deb no mesmo sistema está fora de questão. Em certas situações desesperadoras, você pode converter pacotes específicos usando alien, mas deve se esforçar muito para solucionar problemas que inevitavelmente surgiriam de tais hacks.

Bem, há alien( man page ), que pode converter entre etc. rpm, debmas eu diria que os problemas reais vêm do manuseio de dependências (diferentes nomes de pacotes para o software) e locais de arquivos de configuração.

Claro, se você quer dizer que ambos os tipos de pacotes podem vir da própria distribuição, isso pode ser contornado, mas então por que alguém faria isso... (E você ainda precisaria converter tudo para um ou outro , pois acho que não dpkgsabe ler os bancos de dados de rpme vice-versa.)

Sim, é possível, mas estraga a distribuição.

Os pacotes não são apenas o formato, que pode ser facilmente transferido de um formato para outro.

Nota: as ferramentas de instalação de pacotes precisam ser portadas, porque você gostaria de ter uma lista centralizada de todos os pacotes, versões, dependências, arquivos de configuração, scripts de pré e pós-instalação (se você substituir um pacote por outro, em outro pacote formato, você espera que os scripts de desinstalação (formato antigo) sejam executados a partir do novo sistema de pacotes.

Mas uma distribuição e pacotes são muito mais que um formato de pacotes. Por exemplo, para Debian: queremos colocar os arquivos no lugar correto, queremos fornecer a página de manual, queremos ter alguns scripts comuns de demonização, queremos que o programa seja executado em várias arquiteturas, vários ambientes gráficos, para que um usuário encontre ele se familiarizou dentro de uma distribuição também com novos packages.packages.

No Debian, queremos que os pacotes sejam facilmente construídos pelos usuários (a partir dos fontes), para que alguém possa personalizar alguns pacotes importantes (para ele). Isso requer muita infraestrutura, que a maioria dos autores upstream não pode fornecer (compilação automática e teste em várias arquiteturas, e feito de tempos em tempos). E também específico do Debian são os requisitos de licença, para que seja mais fácil bifurcar um pacote ou distribuição, sem a necessidade de verificar todos os pacotes.

No final, uma distribuição é feita por pacotes consistentes, não apenas por pacotes.

Sim, e a maioria das distros baseadas em .deb já faz isso, mas...

No Debian e famílias relacionadas, pelo menos, você tem o alien, que permitirá a instalação de pacotes RPM.

Você terá os mesmos problemas ao misturar pacotes que não foram projetados para funcionar com sua distro ao instalar pacotes estrangeiros, independentemente do formato - se você instalar um RPM em um sistema baseado em DEB, esse RPM deve ser compatível com seu sistema , como se você estivesse instalando um pacote RPM em um sistema baseado em RPM, e isso é o mas. Você pode fazer isso, mas provavelmente não quer.

Sim e não. deb e rpm são apenas formatos. Você pode suportar ambos os formatos, mas é inútil. Pacotes geralmente não são comparáveis ​​entre distribuições, especialmente distribuições que não são baseadas uma na outra.

Se todas as distribuições tivessem os mesmos requisitos de versão, então tudo o que uma distribuição seria seria uma seleção de pacote. Você pode instalar qualquer distribuição listando os pacotes.

Mas as distribuições devem fornecer software que possam suportar. Se uma biblioteca que faz seu aplicativo funcionar não é mantida e requer uma biblioteca que foi substituída por outra, como você resolve esse conflito? O gerenciador de pacotes não pode portar código. Pode haver vários sucessores escolhidos por diferentes distribuições.