5 ms·

I don't like RPM or Yum. In my experience with using it, it has usually done more harm than good. What other companies use is up to them, but it isn't suitable

I don't like RPM or Yum. In my experience with using it, it has usually done more harm than good. What other companies use is up to them, but it isn't suitable for me. Argumentum ad populum is a fallacy.

untothebreach 12y ago
Sure, ad populum is a fallacy when you are arguing a point, but when you are trying to decide on a toolchain to use, why wouldn't you go with the one that most of your customers use? You might like another toolchain better (and I happen to agree with you about rpm), but that doesn't necessarily mean it is objectively better.
- mdekkers 12y ago
  I didn't argue about it objectively being better, I argued that it isn't suitable for _me_ - given the downvotes though, It appears that I am stupid and don't understand my own use-cases, and the general population on HN knows much better what I need.
  - eropple 12y ago
    I downvoted you not because of your disagreement, though I think you're wrong, but because of your peculiar insistence on self-martyrdom. It doesn't improve your argument and leads only to meta-complaint threads that generally don't go anywhere.
  - untothebreach 12y ago
    (i did not downvote you) This was my interpretation of your comment, my apologies if it is incorrect: "I don't like YUM and RPM, and others shouldn't use popularity as a reason to use something" Which I agree with. However, in this case, I think that if, in fact, RPM is popular among VMWare's customers, choosing that toolchain in order to make their new product more attractive to their existing customers is totally valid.
kondor6c 12y ago
RPM is really a great packaging system. It has a lot of features that DEB's do not, for example you can roll back yum/RPM transaction's if you like (yum history undo ${id}). Another example is to get a list of the last packages that were installed "rpm -qa --last". DEB's seem to prefer to write things to files instead, so they'll write to /var/lib/dpkg/info/* One place where I think that DEB's win, is in building a new package. It was pretty easy for me to make a DEB than an RPM, and the fact that I had a hard time finding which RPM macros did function XXYY. I think the reason why many don't like fedora/centos is the fact that packages aren't easily accessible, because Ubuntu will enable the universe repo by default whereas fedora/centos you would have to install that on your own. If I can help you, feel free to reach out to me.
- mdekkers 12y ago
  I have had many issues with RPM and YUM breaking a system, something that hasn't happened to me deb-based systems. I find rolling custom packages and running an in-house deb repo and mirror to be easy and very reliable. There are quite a few things I don't like about CentOS/Fedora/RH are laid out. Yes, some of these are simply personal preferences, and some of these are based on technical requirements. Live and let live - if it works for you, that's great, I don't have an issue with that. Unfortunately, it seems people have an issue with me not adhering to their own world view - pity HN is going that way. I do genuinely appreciate your offer for help, many thanks :)
  - ominous_prime 12y ago
    No, people are downvoting you because your first comment was about dismissing the article outright when you got to rpm+yum. You haven't made any useful comments regarding the article, just continuing on about how you have personally had non-specific problems with yum and rpm.
  - Alupis 12y ago
    Perhaps you "just did it wrong", and that's the core problem. I know when I'm not familiar with something and I sit down at it for the first time, I make mistakes too... but you shouldn't blame the system for your error. If you are just using yum or dnf, you simply won't break your system.
SEJeff 12y ago
So you've never had to edit a broken maintainer script under /var/lib/dpkg/info/* from bad post/pre install / removal bits? I've used both extensively on somewhere around 30k machines over my career and have to say I see rpm make a mess impossible to fix with just rpm 0 times. I most definitely can not say the same for Debian / Ubuntu systems. I think yum wins in that it has real plugins, not quasi plugins. There is a sort of debdelta-upgrade command, where as yum deltarpm is part of yum natively (you don't have to know about it to use it). The same can be said for the fastest mirror plugin, where yum will ping several mirrors and choose the fastest one for you. I can go on and on, but the moral of the story is that in 2015, from a technical standpoint, yum simply beats apt-get. Bonus points that you have things like rpm -V and rpm -qf (which dpkg -S don't really replicate much at all).
- mdekkers 12y ago
  > "So you've never had to edit a broken maintainer script under /var/lib/dpkg/info/* from bad post/pre install / removal bits?" Nope...
fsloth 12y ago
"Argumentum ad populum is a fallacy." Yes, but when choosing tech it can be a good dimension of analysis if paired with other variables. Popular tools that are maintained if not bug-free can have a better understood bug-portfolio than a more elegant-but-still less used ones. Choosing the devil one knows over the one one don't know and all that.
Alupis 12y ago
> I don't like RPM or Yum. In my experience with using it, it has usually done more harm than good. How is: yum install <package> -y And worse than: apt-get update && apt-get install <package> A lot of people like to say RPM's are horrible, and maybe they are right... but if you use the package manager, what does it matter to you how the packages were made? It just works... I can't think of a single example where something blew up simply because it was an RPM. As a side-note -- the other comments are right, RPM is use an awful lot more in business because most businesses are running some flavor of RHEL/CentOS. If it were really that bad, then it would have been changed by now.
- mercurial 12y ago
  As a guy who has been packaging software for both, and who has been using Debian daily for years, RPM SPEC files are a hell of a lot easier to understand than the Debian packaging system (on the other hand, they're not really machine-readable or easy to generate automatically, so you have to choose your headache).

untothebreach 12y ago

Sure, ad populum is a fallacy when you are arguing a point, but when you are trying to decide on a toolchain to use, why wouldn't you go with the one that most of your customers use? You might like another toolchain better (and I happen to agree with you about rpm), but that doesn't necessarily mean it is objectively better.

mdekkers 12y ago
I didn't argue about it objectively being better, I argued that it isn't suitable for _me_ - given the downvotes though, It appears that I am stupid and don't understand my own use-cases, and the general population on HN knows much better what I need.
- eropple 12y ago
  I downvoted you not because of your disagreement, though I think you're wrong, but because of your peculiar insistence on self-martyrdom. It doesn't improve your argument and leads only to meta-complaint threads that generally don't go anywhere.
- untothebreach 12y ago
  (i did not downvote you) This was my interpretation of your comment, my apologies if it is incorrect: "I don't like YUM and RPM, and others shouldn't use popularity as a reason to use something" Which I agree with. However, in this case, I think that if, in fact, RPM is popular among VMWare's customers, choosing that toolchain in order to make their new product more attractive to their existing customers is totally valid.

kondor6c 12y ago

RPM is really a great packaging system. It has a lot of features that DEB's do not, for example you can roll back yum/RPM transaction's if you like (yum history undo ${id}). Another example is to get a list of the last packages that were installed "rpm -qa --last". DEB's seem to prefer to write things to files instead, so they'll write to /var/lib/dpkg/info/* One place where I think that DEB's win, is in building a new package. It was pretty easy for me to make a DEB than an RPM, and the fact that I had a hard time finding which RPM macros did function XXYY. I think the reason why many don't like fedora/centos is the fact that packages aren't easily accessible, because Ubuntu will enable the universe repo by default whereas fedora/centos you would have to install that on your own. If I can help you, feel free to reach out to me.

mdekkers 12y ago
I have had many issues with RPM and YUM breaking a system, something that hasn't happened to me deb-based systems. I find rolling custom packages and running an in-house deb repo and mirror to be easy and very reliable. There are quite a few things I don't like about CentOS/Fedora/RH are laid out. Yes, some of these are simply personal preferences, and some of these are based on technical requirements. Live and let live - if it works for you, that's great, I don't have an issue with that. Unfortunately, it seems people have an issue with me not adhering to their own world view - pity HN is going that way. I do genuinely appreciate your offer for help, many thanks :)
- ominous_prime 12y ago
  No, people are downvoting you because your first comment was about dismissing the article outright when you got to rpm+yum. You haven't made any useful comments regarding the article, just continuing on about how you have personally had non-specific problems with yum and rpm.
- Alupis 12y ago
  Perhaps you "just did it wrong", and that's the core problem. I know when I'm not familiar with something and I sit down at it for the first time, I make mistakes too... but you shouldn't blame the system for your error. If you are just using yum or dnf, you simply won't break your system.

SEJeff 12y ago

So you've never had to edit a broken maintainer script under /var/lib/dpkg/info/* from bad post/pre install / removal bits? I've used both extensively on somewhere around 30k machines over my career and have to say I see rpm make a mess impossible to fix with just rpm 0 times. I most definitely can not say the same for Debian / Ubuntu systems. I think yum wins in that it has real plugins, not quasi plugins. There is a sort of debdelta-upgrade command, where as yum deltarpm is part of yum natively (you don't have to know about it to use it). The same can be said for the fastest mirror plugin, where yum will ping several mirrors and choose the fastest one for you. I can go on and on, but the moral of the story is that in 2015, from a technical standpoint, yum simply beats apt-get. Bonus points that you have things like rpm -V and rpm -qf (which dpkg -S don't really replicate much at all).

mdekkers 12y ago
> "So you've never had to edit a broken maintainer script under /var/lib/dpkg/info/* from bad post/pre install / removal bits?" Nope...

fsloth 12y ago

"Argumentum ad populum is a fallacy." Yes, but when choosing tech it can be a good dimension of analysis if paired with other variables. Popular tools that are maintained if not bug-free can have a better understood bug-portfolio than a more elegant-but-still less used ones. Choosing the devil one knows over the one one don't know and all that.

Alupis 12y ago

> I don't like RPM or Yum. In my experience with using it, it has usually done more harm than good. How is: yum install <package> -y And worse than: apt-get update && apt-get install <package> A lot of people like to say RPM's are horrible, and maybe they are right... but if you use the package manager, what does it matter to you how the packages were made? It just works... I can't think of a single example where something blew up simply because it was an RPM. As a side-note -- the other comments are right, RPM is use an awful lot more in business because most businesses are running some flavor of RHEL/CentOS. If it were really that bad, then it would have been changed by now.

mercurial 12y ago
As a guy who has been packaging software for both, and who has been using Debian daily for years, RPM SPEC files are a hell of a lot easier to understand than the Debian packaging system (on the other hand, they're not really machine-readable or easy to generate automatically, so you have to choose your headache).