Je ne pensais pas qu'il existe des distributions qui prennent en charge les deux nativement, mais il s'avère qu'il y en a une en développement, Bedrock Linux (merci à iMalinowski pour l'information). Sur d'autres distributions, vous pouvez utiliser des outils de conversion tels que alien convertir d'un format à l'autre. Tout ce qui est basé sur un logiciel est faisable, avec suffisamment de temps et d'énergie, il serait donc possible de construire une telle distribution (mais étant donné les différences entre les capacités de .deb et .rpm colis, assez difficile).
Cependant, tout cela découle probablement de l'idée que la prise en charge des deux formats de packages simplifierait la vie, car vous pourriez alors installer des packages de n'importe où (enfin, n'importe où en fournissant un .deb ou .rpm ). Philosophiquement, c'est faux. Une distribution est un ensemble cohérent de packages; si vous souhaitez fournir un logiciel pour cette distribution, vous devez vraiment la cibler spécifiquement, ce qui inclut l'utilisation de son format de package (et, plus important encore, des métadonnées). Il est inutile de prendre en charge plusieurs formats de package de manière native.
(Dans le monde Debian, les paquets peuvent fonctionner sur des variantes qui ne sont pas leur cible principale, parce que la nomenclature des paquets est plutôt homogène, et parce que la plupart des distributions tiennent dans un arbre d'héritage. Ce n'est pas vrai dans le monde RPM. Dans les deux cas, mélanger et la correspondance est une mauvaise idée.)
Vous devez considérer votre distribution comme une base sur laquelle construire le système souhaité, en respectant les règles et l'écosystème de votre distribution, sans mélanger les éléments d'autres distributions. Vous avez besoin d'abstractions de niveau supérieur pour prendre en charge le mélange et l'appariement (ou plutôt, pour fournir des environnements de distribution croisée) :l'environnement d'exécution Steam, Flatpak, etc.
Bedrock Linux le fait. Je ne dis pas que j'ai fait ça, ou que c'est une bonne idée, mais c'est en train de se faire.
Non, un tel monstre ne devrait pas être construit. Contrairement, par exemple, à un ensemble d'applications MacOS, qui comprend généralement tout ce dont l'application a besoin pour s'exécuter sur le système d'exploitation, les packages RPM et .deb dépendent presque toujours d'autres packages, tels que les bibliothèques partagées. Les packages Linux répertorient les autres packages qui doivent être présents et le gestionnaire de packages aide à appliquer ces exigences. De plus, les distributions Linux diffèrent dans la façon dont les choses sont faites (par exemple, /etc/network/interfaces.d vs /etc/sysconfig/network-scripts ).
Vous ne devriez même pas mélanger des packages provenant de référentiels arbitraires au sein de la même famille de formats de packages. Autrement dit, l'installation de packages SuSE sur une machine CentOS ne demande que des problèmes, même s'ils utilisent tous les deux RPM. Je n'installerais même pas de packages destinés à une version différente du même système d'exploitation (par exemple, les packages Ubuntu 14.04 sur un système 16.04) à moins de savoir exactement ce que je fais.
Il est donc hors de question d'essayer de prendre en charge à la fois RPM et .deb sur le même système. Dans certaines situations désespérées, vous pouvez convertir des packages spécifiques en utilisant alien , mais vous devez vous attendre à déployer beaucoup d'efforts pour résoudre les problèmes qui résulteraient inévitablement de tels piratages.