I am wondering if it is theoretically possible to build a Linux distro that can both support rpm and debian packages.

Are there any distros live out there that support both?

And if not is it even possible?

  • 4
    Unless we consider packages with a noncomputable number of dependencies, I don't see how installing them can be theoretically impossible. Dec 12, 2017 at 9:07
  • 2
    It would be possible if you left dependency resolution to the user :) Dec 12, 2017 at 22:40
  • @rackandboneman in that case, Slackware plus alien to convert packages to .tgz files would work :) If you use the source debs or rpms LFS could do it as well.
    – ivanivan
    Dec 13, 2017 at 2:53
  • @DmitryGrigoryev IIRC, dependency resolution is NP-complete when you allow for negative dependencies (conflicts).
    – user253751
    Dec 13, 2017 at 6:04
  • @immibis NP-complete implies computable. Noncomputable means e.g. "if this program hangs up with libc5, install libc6". Dec 13, 2017 at 12:06

7 Answers 7


I didn’t think there are any distributions out there which support both natively, but it turns out there is one in development, Bedrock Linux (thanks to iMalinowski for the information). On other distributions you can use conversion tools such as alien to convert from one format to the other. Anything software-based is doable, given enough time and energy, so it would be possible to build such a distribution (but given the differences between the capabilities of .deb and .rpm packages, quite difficult).

However all this probably stems from the idea that supporting both package formats would make life simpler, because you could then install packages from anywhere (well, anywhere providing a .deb or .rpm). Philosophically, that’s flawed. A distribution is a coherent set of packages; if you want to provide software for that distribution, you really need to target it specifically, which includes using its package format (and more importantly, metadata). There’s no point in supporting multiple package formats natively.

(In the Debian world, packages can work on variants which aren’t their main target, because the package nomenclature is rather homogeneous, and because most distributions fit in an inheritance tree. That’s not true in the RPM world. In both cases mixing and matching is a bad idea.)

You should consider your distribution as a base on which to build your desired system, sticking to your distribution’s rules and ecosystem, without mixing things in from other distributions. You need higher-level abstractions to support mixing and matching (or rather, to provide cross-distribution environments): the Steam runtime, Flatpak, etc.


Bedrock Linux does this. Not saying I've done this, or that it is a good idea, but it is being done.


No, such a monster should not be built. Unlike, say, an MacOS application bundle, which typically includes everything the application needs to run on the operating system, RPM and .deb packages are almost always dependent on other packages, such as shared libraries. Linux packages list the other packages that need to be present, and the package manager helps enforce those requirements. Furthermore, Linux distributions differ in the way things are done (e.g. /etc/network/interfaces.d vs. /etc/sysconfig/network-scripts).

You shouldn't even mix packages from arbitrary repositories within the same package format family. That is, installing SuSE packages on a CentOS machine is just asking for trouble, even though they both use RPM. I wouldn't even install packages intended for a different version of the same OS (e.g. Ubuntu 14.04 packages on a 16.04 system) unless I knew exactly what I was doing.

So, trying to support both RPM and .deb on the same system is out of the question. In certain desperate situations, you could convert specific packages using alien, but you should expect to put a lot of effort into troubleshooting problems that would inevitably arise from such hacks.

  • 3
    Even for distros originating from the same family, mixing packages can be a bad idea. For example Debian and Ubuntu are both .deb based but Ubuntu have made some design decisions that differs from Debian so using Ubuntu packages in Debian may not always work.
    – slebetman
    Dec 12, 2017 at 2:07
  • 1
    Even mixing Debian distro versions is a bad idea: wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian
    – stanri
    Dec 12, 2017 at 6:02
  • Then there's Mint that's based on Ubuntu that's based on Debian... :-)
    – DevSolar
    Dec 13, 2017 at 13:31
  • 1
    I am not going to say I think it is a good idea. At the same time, I fail to see why it is such a horrible idea. I think these problems could be overcome - it's just that there is no real reward for doing so.
    – emory
    Dec 13, 2017 at 16:00

Well, there's alien (man page), that can convert between rpm, deb etc., but I would assume the actual problems come from handling dependencies (different package names for the software), and locations of configuration files.

Of course, if you mean that both types of packages could come from the distribution itself, that could possibly be worked around, but then why would anyone do that... (And you'd still need to convert everything to one or the other, since I don't think dpkg knows how to read the databases of rpm and vice versa.)


Yes, it is possible, but it ruins the distribution.

Packages are not just the format, which can be easy ported from one format to the other.

Note: package installation tools need to be ported, because one would like to have a centralized list of all packages, versions, dependencies, configuration files, pre- and post install scripts (if you replace one package with an other, in an another package format, you expect that the disinstallation scripts (old format) are run from new package system.

But a distribution and packages are much more than a format of packages. E.g. for Debian: we want to put files in the correct place, we want to provide the manual page, we want to have some common deamonizing scripts, we want that the program runs in many architectures, various graphical environment, so that a user finds himself familiar inside a distribution also with new packages.packages.

In Debian we want that packages are easily buildable by users (from sources), so that one could customize some important (for him) packages. This requires a lot of infrastructure, which most upstream authors cannot provide (automatic build and test on various architectures, and done from time to time). And also Debian specific is the requirements of license, so that it is easier to fork a package or distribution, without need to check all packages.

At the end, a distribution is made by consistent packages, not just by packages.


Yes and most .deb based distros already does it, but...

On Debian and related families, at least, you have alien, which will allow you to install RPM-packages.

You will have the same problems when you mix packages that wheren't designed to work with your distro when you install foreign packages regardless of the format -- if you install an RPM on a DEB based system, that RPM must be compatible with your system, just as if you're installing an RPM package on an RPM based system, and that's the but. You can do it, but you probably don't want to.


Yes and no. deb and rpm are just formats. You can support both formats but its pointless. Packages are not generally comparable between distributions especially distributions that are not based on one another.

If all distributions had the same versioning requirements then all a distribution would be is a package selection. You could install any distribution by listing the packages.

But distributions must provide software that they can support. If a library that makes your application work isn't maintained and itself requires a library that has been superseded by something else how do you resolve this conflict? The package manager can't port code. There may be multiple successors chosen by different distributions to.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .