Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm a Debian fanboy, but in all honesty, the RPM-based distros have long since caught up with apt in terms of sophistication.

I did find yum (the apt equivalent used by Red Hat and friends) a bit slow (it's written in Python) and slightly rough on the usability front in some cases, but perfectly serviceable.

Mandriva and its derivatives (Mageia is worth looking at) use urpmi to provide the equivalent of apt. I really, really like urpmi, but none of the distros that use it have satisfied me (for unrelated reasons).

SuSE and friends have advanced package management baked into YaST, which handles other configuration and setup tasks as well. I haven't used SuSE in ages, but it the package management seems pretty robust.



It's a bit sad that many people attribute yum's slowness to Python. Most of that is because it builds an XML db every single time it runs.


Absolutely. Package managers are mostly IO-bound so there is no reason why a Python-based PM should be substantially slower than a C implementation.


Except when they are calculating dependencies

But I agree with the yum sentiment, it really looks bad when compared to other solutions that existed: urpmi, apt-rpm, etc


Yeah, i've always found that quite odd. Do you seriously need to refresh the package db every. single. time? I might agree that cron-based/user-initiated solutions are suboptimal (some users will just not bother, which is a security and support problem), but surely there is a compromise, like limiting the refresh to once a week.

(Cue some RedHat fanboi saying "but it's easy, you just do xyz" -- no, it's not easy unless it's default behaviour. Otherwise we might as well just run OpenBSD, because opening network ports every time you have to sneeze is "so easy".)


Yum is getting replaced in Fedora as well.

https://fedoraproject.org/wiki/Features/DNF


Now that yum and apt have feature-parity, shouldn't picking a single package format (rpm/deb) be an easier choice now?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: