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?
Bedrock Linux does this. Not saying I've done this, or that it is a good idea, but it is being done.
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
.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
.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.
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.
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.
alien (man page), that can convert between
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.
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.