Lots of actual businesses use RHEL and even centos (including the company I work for, which uses centos 7 even for production), and by extension using rpm. Our local laptops are Ubuntu (and we use docker to do local dev, with a centos-based image obv). BTW I never got the civil war between rpm and deb. As a person coming from Windows, I 'd expect each distribution's native package manager to be able to use either, much like Windows can work with both wmv and mp4. I guess it's a deeper problem, having to cho
They have separate databases (unlike Windows, Linux package managers actually track all the files they 'own').
More importantly, packages all have to work together because they know what other packages and versions of packages and versions of libraries they depend on. So RPMs from Fedora will likely not install on CentOS, etc. Installing a deb would be 'good luck with that' even if you had a version of dpkg that used rpm or dnf's database.
So, the answer is: You can convert between Deb and RPM, but the repos that the dependencies expect aren't the same. So it's not about the file format, but the repos (totally not a walled garden btw).
They do no such thing. The fact you CAN compile from source is.. the alternative.
You clearly don't have a clue how RPMs and DEBs work. There are databases and whatnot... It would not be an easy undertaking to support both. If you want an alternative to DEB or RPM on whatever distro, you're welcome to compile from source. Your freedom to do so doesn't mean you get to demand that developers put in the sweat equity to maintain two package systems.
Where did this come from? On the CentOS/RHEL side you can add EPEL, NUX, and google-chrome, make sure to import the public key so you can verify those RPMS.
Don't want to add a repo like and just want a single program, you can download the RPM and yum localinstall it.
That's because they disagree on how to do things, which is why they are separate Operating systems in the first. place.
Although if you want Distro independent packaging, you can kind of get it with Cannonical's snaps. Which I hate for various reasons, but it mostly works. There are other solutions that do similar things as well.
So they are incompatible gardens not walled gardens, each with different philosophies. You say "their" repository and use the word "ecosystem", making it sound exclusive like an apple store, NUX is not owned or maintained by Redhat.
If I wanted to distribute my own software via RPM/YUM, I do not have to get a license, cert or anything from RHEL to distribute it. Also I do not have to root my install for a third party repo.
I am free to choose a third party repo if I wanted even if it will make my system uns
Guess what, most people are stupider than me. Here is how we stupid 99% see it: Desktop Linux has a tiny ecosystem, so let's split it up among several "repositories" hosting outdated versions of the apps each. Desktop Linux deserves to be an 1% OS for nerds, and when secure boot slowly eventually creeps into almost every PC compatible out there, it will be 0.1%, and then you will have the same hardware compatibility as FreeBSD (best case) or Illumos (worst case).
Flatpak and snaps are OK, but they are pretty much limited to their own universes, be it RHEL or Debian/Ubuntu.
I have found AppImage works well, regardless the distro in use, and isn't tied to the cloud either. Just run it and call it done. Downside of AppImage is that the docs for building packages under it are tough, and the learning curve to build something with it is very steep, compared to snaps or flatpaks.
Most often you can find a binary version of the package, that fits the dependencies and it's still (usually) mindbogglingly simple to build the required package from source.
Holy crap, people still use those distros? (Score:-1)
Who the hell still uses a Redhat packaging distro in 2020. Crazy people.
Re: (Score:2)
Re: (Score:2)
They have separate databases (unlike Windows, Linux package managers actually track all the files they 'own').
More importantly, packages all have to work together because they know what other packages and versions of packages and versions of libraries they depend on. So RPMs from Fedora will likely not install on CentOS, etc. Installing a deb would be 'good luck with that' even if you had a version of dpkg that used rpm or dnf's database.
Re:Holy crap, people still use those distros? (Score:2)
Re: (Score:1)
Re: (Score:1)
Try to tie you down?
They do no such thing. The fact you CAN compile from source is .. the alternative.
You clearly don't have a clue how RPMs and DEBs work. There are databases and whatnot... It would not be an easy undertaking to support both. If you want an alternative to DEB or RPM on whatever distro, you're welcome to compile from source. Your freedom to do so doesn't mean you get to demand that developers put in the sweat equity to maintain two package systems.
By the way, freedom doesn't mean
Re: (Score:1)
Where did this come from? On the CentOS/RHEL side you can add EPEL, NUX, and google-chrome, make sure to import the public key so you can verify those RPMS.
Don't want to add a repo like and just want a single program, you can download the RPM and yum localinstall it.
I see freedom right there.
Re: (Score:2)
Re: (Score:2)
That's because they disagree on how to do things, which is why they are separate Operating systems in the first. place.
Although if you want Distro independent packaging, you can kind of get it with Cannonical's snaps. Which I hate for various reasons, but it mostly works. There are other solutions that do similar things as well.
Re: (Score:1)
So they are incompatible gardens not walled gardens, each with different philosophies. You say "their" repository and use the word "ecosystem", making it sound exclusive like an apple store, NUX is not owned or maintained by Redhat.
If I wanted to distribute my own software via RPM/YUM, I do not have to get a license, cert or anything from RHEL to distribute it. Also I do not have to root my install for a third party repo.
I am free to choose a third party repo if I wanted even if it will make my system uns
Re: (Score:1)
Holy fuck are you stupid
Re: (Score:2)
Re: (Score:2)
Which is why flatpak makes sense.
Re: (Score:2)
Flatpak and snaps are OK, but they are pretty much limited to their own universes, be it RHEL or Debian/Ubuntu.
I have found AppImage works well, regardless the distro in use, and isn't tied to the cloud either. Just run it and call it done. Downside of AppImage is that the docs for building packages under it are tough, and the learning curve to build something with it is very steep, compared to snaps or flatpaks.
Re: (Score:2)