3 ms·
Nowadays, that actually isn't very true for end-users - rpm is catching up really fast in all the areas that dpkg was formerly better in. A good StackExchange
by ek 14y ago
Nowadays, that actually isn't very true for end-users - rpm is catching up really fast in all the areas that dpkg was formerly better in.
A good StackExchange thread: http://unix.stackexchange.com/questions/634/what-are-the-pros-cons-of-deb-vs-rpm http://unix.stackexchange.com/questions/634/what-are-the-pro...
- grandalf 14y agoDoes RPM have any advantages?
- Spidler 14y agoBetter integrity checks, mostly. Built in checksums of files, stricter limits on what you can do as a package ( no controlling terminal and so on ) whereas in deb it's "optional" and "flexible" (aka. not built in and maybe people will get together and decide something) rpm has some build time analysing tools to track library (.so, python, perl, php, ruby imports) use and annotate this as dependencies. This above feature is one that causes the mess when you don't have the full dependency graph for a package, because rpm by itself does no dependency resolution.
- noselasd 14y agoAs a developer, I'm actually able to easily package stuff with rpm. creating .debs is stupidly frustrating
- vidarh 14y agoWhenever I've wanted to package .deb's I've just blatantly ignored the official way, and opted for a much simplified setup (write the control file and the pre/post-int scripts, and use a Makefile to build the filesystem hierarchy required and run the appropriate tools). I agree, though, as much as the RPM spec files are horrible, it's still overall simpler.