Multiple package manager [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 9 years ago.

Improve this question

Is there a pitfall of using multiple package managers? Could I use Redhat's yum with Debian's aptitude at the same time?

I came across this article and this infographic -

I was inclined to choose Debian, but a quick VM install showed that the Kernel is not upgraded to 3.2 in the stable repo yet. So I am planning to move to Archlinux, but the infographic rates it low on package availablity and I was wondering if I could install .deb or .rpm files from the Fedora or Ubuntu repositories.

Answer 1

The short answer is, yes you can, but you really shouldn't.

Below is a list of things (in no particular order) to consider when cross-distribution installing:

• Dependency hell

The primary reason things like yum/apt/yast exist in the first place is to avoid what is known as dependency hell. By using packages from other systems, you forfeit the work that has been put into the packages from installing cleanly.

The secondary package manager will want to satisfy its own dependencies, and install a bunch of things that are already installed. This means you have to install packages a piece at a time so that you don't overwrite already installed packages from your primary package manager, and have all kinds of problems.

• Do they use the same package manager?

If they do, you may even be able to just install it outright, but you'll likely have dependancy issues or package conflicts. If they don't, you can extract the package with various tools and just lay down the binary files onto the file system (have a look at alien, or this post about extracting .rpm and .deb files).

This will get you the files on the system, but there is no guarantee it'll work out of the box. Some additional manual hunting may be (and usually is) required.

• Are the versions of base packages such as glibc the same or very close?

If so, there is less chance of an issue. The further difference between the two distribution's base packages, the more likely you'll have missing shared libraries that aren't available in the distribution you're running on, because the version is different and the filename doesn't match what the binary is looking for.

Technically you could also extract the base dependencies from the other distribution and put them on the filesystem as well, but that will certainly cause you pain should you ever need to compile things from source. Imagine how confused gcc will be.

• Does the package you're installing call for a specific kernel module?

The best way I can articulate this is a common problem I see these days with buying VMs from a web host; you get their own brand of xen or virtuozzo kernel, and iptables doesn't work outright because netfilter is in the kernel and the ABI has changed. It can be quite the headache to get it working again, and this issue isn't limited to iptables. My best advice here is pick the distribution that has the kernel you want in its own base repository.

• Compiling from source

No doubt you'll have to do this should you get very deep into wanting packages from other systems. Since the various distros setup their build environments differently, you'll be spending half your time figuring out pathing and other configuration issues.