3 ms·

Red Hat or the Microsoft of Linux is the face palm of linux distros, forget dependency hell, how on earth someone choose rpm over first class Superior Debian pa

Red Hat or the Microsoft of Linux is the face palm of linux distros, forget dependency hell, how on earth someone choose rpm over first class Superior Debian package system or distros like Ubuntu? People just buy it for the support even if the Red Hat they use is Gnome 2 and Firefox V.3.0. Then finally RHCA/RHCE courses, i should get certified from this distro to prove my Linux skills for the companies even though i am a debian guy? No Thanks.

kbenson 10y ago
> how on earth someone choose rpm over first class Superior Debian package system So, what makes the Debian package system superior? Having built multiple specs in the past, but not any debs, I'm curious. Given that you can often convert debs to RPMs and vice-versa, and can use the different package managers on either type of repository, it's not obvious where one has any specific benefit.
- chousuke 10y ago
  I've built both Debian packages and RPMs, and I feel that RPMs are somewhat easier to wrap your head around. It's been a while since I did Debian package building, though. It's also undeniably true that there was a time when APT + dpkg blew Red Hat's "equivalent" tools out of the water, but that's not the case anymore. One thing I like in particular about dnf/rpm is that I can install packages by using functions, so eg. telling yum to install perl(Net::DNS) will work and installs the perl-Net-DNS package. I'm not sure if apt can do this.
  - lima 10y ago
    And SPEC files are much easier to work with than Debian's folder full of different files.
    - snuxoll 10y ago
      This is my biggest gripe with debian packaging. Also, the use of make files and the magic that goes on behind the scenes with debhelper (which you probably want to use) makes packaging much less transparent. It took me days to grok how to make a proper debian package nearly a decade ago when I first did it - writing my first .spec file took an hour or so and now I can hammer most of them out in 15 minutes or less.
- houst0n_ 10y ago
  There is no difference. From the top of my head in the last few years I have (and you have also probably) used the following to get software: rpm/yum, deb/apt, pacman, ports, sysvr4(Solaris), ips, homebrew, pkgin, npm, gem, pip, hex, cpan and hmmm probably a few others. They all do pretty much the same thing, one might have prettier progress bars or a better cli but we're just talking compressed tars with some metadata files. Competition is good and all that, but how much innovation do we need to drive in package managers? We have lots of tools all doing the same thing with negligible advantages over their competitors and I don't see it as a positive.
- jhasse 10y ago
  I have built both debs and rpms and I like rpms more. Both aren't perfect though (still so much fiddling around with Bash in pre/post scripts for doing anything more then extracting a bunch of files).
- scrame 10y ago
  its not that .deb is a better than format than .rpm, but apt is better than yum, as a dependency manager.
  - kbenson 10y ago
    I've actually never found that to be true, mostly due to a wird cognitive disconnect between the desired outcome and the actions you need to perform. Either use separate commands for different actions, or distinguish actions with arguments, but don't do both. E.g. apt-get install, apt list, apt-file update.
  - FooBarWidget 10y ago
    To be fair, there is one thing that .deb is better at than .rpm: support for optional/recommended dependencies.
- dredmorbius 10y ago
  Ultimately, Debian Policy. The software tools and packaging formats exist only to implement that. It's Policy and the comprehensiveness of the Debian archive (60k+ packages last time I checked, a year or so back), which make it bliss. You simply rarely have to go outside it, and you can configure a system as lean or rich, or anywhere in between, as you like. What Policy states is that the package maintainer (not the user) must or must not do, including incorporating specified, requiring manpages (though that's not a release-critical bug), so that documentation is standardised. The fact that /usr/share/doc/ has every single package installed listed in it, and they don't include the installed version number in the directory names, as RH still does, means that you can use that directory to recover or rebuild from various packaging failures. (Why would you want to do that you ask? Same reason you'd want to have a doctor or hospital nearby if you had a broken leg -- it's not so much what you'd planned on, but it's damned convenient when you find yourself in that situation.) Joey Hess and Martin Krafft (see the latter's The Debian System) both expanded on more elements of Debian packaging vs. other systems, particularly Red Hat / RPM. http://www.worldcat.org/title/debian-system/oclc/640083534&referer=brief_results http://www.worldcat.org/title/debian-system/oclc/640083534&r...
  - kbenson 10y ago
    > The fact that /usr/share/doc/ has every single package installed listed in it, and they don't include the installed version number in the directory names, as RH still does, means that you can use that directory to recover or rebuild from various packaging failures. Why wouldn't you want the version numbers? That seems like something you would want when trying to rebuild a package database. Also, what do you do if you have two versions of something installed ?
    - dredmorbius 10y ago
      1. Generally you rebuild to the latest available versions of yor specified release. APT sorts version deps as it does package deps, so you don't have to. 2. You can reference content under /usr/share/doc/ without having to specify a goddamned version number that a) changes arbitrarily and b) is inconsistently specified every fucking time. Version numbers are metadata, not directory name elements. Changelogs, also required, give you the info if you desperately neeed it.
greenshackle2 10y ago
Why would you use Ubuntu with it's repository of stale packages and over-engineered package system when you can use pacman on Arch? On Ubuntu you end up having to add a bunch of PPAs if you need up-to-date software for any reason, then it's a nightmare to maintain. People just use it because of its convenient point and click interface and config utilities. Why should I learn to use a mouse even though I'm a command line ninja? No thanks. (Note: satire. I use and love both Ubuntu and Arch.)
TallGuyShort 10y ago
So you have an opinion on a religious war and take issue with companies over-valuing Red Hat certifications? Oh my gosh they're literally the devil.

kbenson 10y ago

> how on earth someone choose rpm over first class Superior Debian package system So, what makes the Debian package system superior? Having built multiple specs in the past, but not any debs, I'm curious. Given that you can often convert debs to RPMs and vice-versa, and can use the different package managers on either type of repository, it's not obvious where one has any specific benefit.

chousuke 10y ago
I've built both Debian packages and RPMs, and I feel that RPMs are somewhat easier to wrap your head around. It's been a while since I did Debian package building, though. It's also undeniably true that there was a time when APT + dpkg blew Red Hat's "equivalent" tools out of the water, but that's not the case anymore. One thing I like in particular about dnf/rpm is that I can install packages by using functions, so eg. telling yum to install perl(Net::DNS) will work and installs the perl-Net-DNS package. I'm not sure if apt can do this.
- lima 10y ago
  And SPEC files are much easier to work with than Debian's folder full of different files.
  - snuxoll 10y ago
    This is my biggest gripe with debian packaging. Also, the use of make files and the magic that goes on behind the scenes with debhelper (which you probably want to use) makes packaging much less transparent. It took me days to grok how to make a proper debian package nearly a decade ago when I first did it - writing my first .spec file took an hour or so and now I can hammer most of them out in 15 minutes or less.
houst0n_ 10y ago
There is no difference. From the top of my head in the last few years I have (and you have also probably) used the following to get software: rpm/yum, deb/apt, pacman, ports, sysvr4(Solaris), ips, homebrew, pkgin, npm, gem, pip, hex, cpan and hmmm probably a few others. They all do pretty much the same thing, one might have prettier progress bars or a better cli but we're just talking compressed tars with some metadata files. Competition is good and all that, but how much innovation do we need to drive in package managers? We have lots of tools all doing the same thing with negligible advantages over their competitors and I don't see it as a positive.
jhasse 10y ago
I have built both debs and rpms and I like rpms more. Both aren't perfect though (still so much fiddling around with Bash in pre/post scripts for doing anything more then extracting a bunch of files).
scrame 10y ago
its not that .deb is a better than format than .rpm, but apt is better than yum, as a dependency manager.
- kbenson 10y ago
  I've actually never found that to be true, mostly due to a wird cognitive disconnect between the desired outcome and the actions you need to perform. Either use separate commands for different actions, or distinguish actions with arguments, but don't do both. E.g. apt-get install, apt list, apt-file update.
- FooBarWidget 10y ago
  To be fair, there is one thing that .deb is better at than .rpm: support for optional/recommended dependencies.
dredmorbius 10y ago
Ultimately, Debian Policy. The software tools and packaging formats exist only to implement that. It's Policy and the comprehensiveness of the Debian archive (60k+ packages last time I checked, a year or so back), which make it bliss. You simply rarely have to go outside it, and you can configure a system as lean or rich, or anywhere in between, as you like. What Policy states is that the package maintainer (not the user) must or must not do, including incorporating specified, requiring manpages (though that's not a release-critical bug), so that documentation is standardised. The fact that /usr/share/doc/ has every single package installed listed in it, and they don't include the installed version number in the directory names, as RH still does, means that you can use that directory to recover or rebuild from various packaging failures. (Why would you want to do that you ask? Same reason you'd want to have a doctor or hospital nearby if you had a broken leg -- it's not so much what you'd planned on, but it's damned convenient when you find yourself in that situation.) Joey Hess and Martin Krafft (see the latter's The Debian System) both expanded on more elements of Debian packaging vs. other systems, particularly Red Hat / RPM. http://www.worldcat.org/title/debian-system/oclc/640083534&referer=brief_results http://www.worldcat.org/title/debian-system/oclc/640083534&r...
- kbenson 10y ago
  > The fact that /usr/share/doc/ has every single package installed listed in it, and they don't include the installed version number in the directory names, as RH still does, means that you can use that directory to recover or rebuild from various packaging failures. Why wouldn't you want the version numbers? That seems like something you would want when trying to rebuild a package database. Also, what do you do if you have two versions of something installed ?
  - dredmorbius 10y ago
    1. Generally you rebuild to the latest available versions of yor specified release. APT sorts version deps as it does package deps, so you don't have to. 2. You can reference content under /usr/share/doc/ without having to specify a goddamned version number that a) changes arbitrarily and b) is inconsistently specified every fucking time. Version numbers are metadata, not directory name elements. Changelogs, also required, give you the info if you desperately neeed it.

greenshackle2 10y ago

Why would you use Ubuntu with it's repository of stale packages and over-engineered package system when you can use pacman on Arch? On Ubuntu you end up having to add a bunch of PPAs if you need up-to-date software for any reason, then it's a nightmare to maintain. People just use it because of its convenient point and click interface and config utilities. Why should I learn to use a mouse even though I'm a command line ninja? No thanks. (Note: satire. I use and love both Ubuntu and Arch.)

TallGuyShort 10y ago

So you have an opinion on a religious war and take issue with companies over-valuing Red Hat certifications? Oh my gosh they're literally the devil.