Many package managers - .deb on RedHat/CentOs

Question

(relatively new to Linux distros)

What forbids me from installing a .deb package (using apt or dpkg) on Redhat/CentOS? Or a .rpm package in Debian/Ubuntu?

I understand Debian/Ubuntu based systems use apt and dpkg (.deb files) as their package manager, and RedHat based systems use .rpm. But are these just conventions/preferences or is the difference more profound?

Every page on the Internet describing how to install .deb packages on RedHat/CentOs discusses how to transform to .rpm file first.
But what fundamentally forbids someone from installing dpkg or apt in RedHat/CentOS, and then using it to install a .deb file directly?

My understanding is that both .deb and .rpm are just fancy tarballs! The underlying binary should be able to run in both RedHat/CentOs and Debian, correct? I mean if I were to manually have the same executable in both distros, then it should run in both? (If not then I would understand the incompatibility between .rpm and .deb off course)

Bonus question: When someone wants to distribute a binary into the Linux world, how many systems does he have to to support and package the binary into? (obviously as many as he wants, but you get my point)

I find it suspicious and bit frustrating that no-one seems to have had this question before. It's possible I am missing something basic, being relatively new to this.
Any documentation on the matter would also be welcomed.

Answer 1

Nothing usually forbids you from mixing different package managers on the same system (although distros usually modify packaged foreign package managers so that they cannot install foreign packages), even though in general that would be pretty much frowned upon unless you really know what you are doing. The following are most of the reasons why it might be a very bad idea:

• Package managers are in charge and assume the notion of managing the filesystem, tracking it in their own databases. Mixing different package managers means each one tracks pathnames being unaware of the others, so they will happily ignore f.ex. versioned dependency requirements and file conflicts and end up overwriting pathnames from other package managers causing unexpected and hidden versioned dependency unsatisfiability.
• While package formats should in general have more or less feature parity, they still can have significant semantic differences. They also are not just containers for the filesystem payload, they also contain package metadata, including dependency information, maintainer scripts or scriplets that will execute setup, fixup or cleanup actions, automatic triggering actions, etc.
• In addition, a big difference between distros (even within the same family using the same package manager) comes from their policies, and how things are integrated together (such as where to place stuff on the filesystem, where and how to register stuff, etc) which in many cases use distro-specific or package-manager-specific interfaces (say like dpkg-divert), default build flags, packaging granularity (how and where to split upstream projects into distro packages), upstream features to enable, how and how much to diverge from upstream (if at all, f.ex. some distros have a 0-divergence policy, while others will happily bump a shared library SONAME if upstream has broken its ABI, but is not going to release a fix for that).
• Nothing guarantees that what is known by a name in distro A will be the same upstream project in distro B, the namespaces are independent, even the versionspaces. There are and have been many conflicting namespace collisions upstream, and that is not easy to be universally represented, so even with dependency metadata, that might not be meaningful when crossing distro boundaries. When it comes to the versionspace, distros use features like version epochs (if they have that notion) at different points in time or for different reasons, or version revert tricks such as 1.0really2.0 to avoid unnecessary epoch usage.
• Related to the above point and the distro divergence one, because some distros patch upstreams, nothing guarantees the programs or shared libraries or other interfaces will be API or ABI compatible, not to mention things like different default build flags and similar.

So, all in all, can you mix and match package managers on the same system? If you make sure f.ex. that they will manage completely independent filesystem hierarchies, then that might work, say either via their own chroots or by one f.ex. managing / and the other /opt. Otherwise your best bet is to convert the package format (as has been mentioned with say alien) and use that to try to funnel those foreign packages into the native package system, but even that will not guarantee a successful endeavor. But otherwise, I'd strongly recommend against this practice. I even recommend against installing say, Ubuntu packages into a Debian system (the former being a derivative of the latter), and for dpkg I'd really like to make it refuse those and require a new force option such as --force-vendor or similar.

For the question of how upstreams are supposed to handle this diversity, my preferred and recommended solution is that they follow upstream best practices so that their project becomes easy to package by the various distros (see f.ex. https://wiki.debian.org/UpstreamGuide), and either participate there or let the distro packagers handle those. Barring that it's perhaps preferable to use one of the various container formats that are supposed to be "universal", even though, of course there are already several competing formats (stuff like snap, flatpak, appimage, etc), so you are again going to have to decide. I think upstreams in general either do not handle packaging, or chose a couple of mainstream formats to focus exclusively on those (say .deb and .rpm).