6 ms·

""We chose Debian because packages and apt [Debian's basic software package programs] are light-years of RPM (Red Had and SUSE's default package management syst

by joshAg 14y ago

""We chose Debian because packages and apt [Debian's basic software package programs] are light-years of RPM (Red Had and SUSE's default package management system.]”" Would someone mind giving a brief overview of why apt is better than rpm (or why someone might think this?)?

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 ago
  Does RPM have any advantages?
  - Spidler 14y ago
    Better 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 ago
    As a developer, I'm actually able to easily package stuff with rpm. creating .debs is stupidly frustrating
    - vidarh 14y ago
      Whenever 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.
strictfp 14y ago
I'm just a casual user, and I didn't really notice any difference between deb and rpm. But I did notice a significant difference between apt and yum. Yum was much slower and less clever in figuring out dependencies. I've had yum uninstall unrelated programs sharing libs with the one being uninstalled. It seems like apt(itude) has more advanced resolution algos built in. Plus more is avail as deb than rpm, no need for manual download via websites.
- ableal 14y ago
  I'll second this. It is also my experience, having used both Fedora and CentOS (2002-2008) and Ubuntu (2004 to now).
- hessenwolf 14y ago
  For me apt is yum, so I've never bothered to check whether yum is apt. I'll get my coat and leave this comment thread now.
carlesfe 14y ago
Do rpm-based managers still work out the package dependences incorrectly, take a long time to download the headers, and generally break constantly? Honest question, I haven't used an RPM-based distro since a couple of years ago. Last was opensuse 11, then fedora 3. rpm is a pretty great format, but the frontends are not very good. apt, on the other hand, rocks, and aptitude rocks even more.
- chalst 14y ago
  Note that both apt-get and aptitude, together with dpkg, are part of APT (advanced packaging tool), which is the suite of tools handling .deb packages. While I'm at it, neither apt-get nor aptitude are simply front ends to dpkg - both have fairly complex (and different) policies for how to handle dependency conflicts, etc, while dpkg makes you do everything by yourself. See http://superuser.com/questions/93437/aptitude-vs-apt-get-which-is-the-recommended-aka-the-right-tool-to-use http://superuser.com/questions/93437/aptitude-vs-apt-get-whi...
bad_user 14y ago
I haven't noticed much of a difference between apt and rpm, but the one thing that keeps me on Debian and Ubuntu (versus other distributions or OS X) is the huge and properly maintained Debian software repository that has no competition.
wtracy 14y ago
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.
- lucian1900 14y ago
  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.
  - ch0wn 14y ago
    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.
    - raverbashing 14y ago
      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
  - toyg 14y ago
    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".)
retube 14y ago
I haven't used rpm for a while having left redhat for ubuntu years back so this may be out of date: but certainly at the the time rpm was famous for "dependency hell" and deservedly so - almost everything I tried to install was a circular nightmare of incompatible dependencies. To the extent that i'd have to give up or resort to compiling from source. OTOH, apt was an absolute dream. It just worked. It'd fish anything required out of remote depository. There were never any version incompatabilities. I've never once had a failed install. On moving to apt I never looked back and would never use rpm again: indeed for me apt was Ubuntu's "killer feature".
- lutusp 14y ago
  > I haven't used rpm for a while having left redhat for ubuntu years back so this may be out of date: but certainly at the the time rpm was famous for "dependency hell" and deservedly so ... True, but since then yum has taken over from rpm, and yum automatically resolves dependency issues. Just saying. All major distributions have tools that avoid dependency hell, in one way or another. The bad old days of rpm trying to sort things out on its own -- and failing -- are gone, and good riddance. > On moving to apt I never looked back and would never use rpm again. Yes, but it's important to point out that Red Hat / Fedora users don't use rpm any more either.
- vidarh 14y ago
  apt is not the equivalent of rpm. dpkg is the equivalent of rpm. And dpkg is equally dumb (both of them "by design" - it's not what they're meant to do) But Yum and Apt as well as other tools have been available to do automatic dependency resolution on RPM based distros for many years - I believe at least apt-rpm predates Ubuntu.
eikenberry 14y ago
It was never about the packing format (dpkg, rpm) nor about the management system (apt, yum)... it was ALWAYS about the number of packages and how well integrated they were and still are. Debian based distros still have the upper hand here as everything belongs to the official distro and is packaged as part of the whole system. RPM based distros all seem to go for the idea of the smaller core set of packages with other repositories filling out other parts of the ecosystem. It just doesn't work as well.
sandGorgon 14y ago
I'm actually surprised that this is the case. I dont know if yum's slowness (as a by product of its implementation) is one of its shortcomings, but I always presumed that it was more sophisticated as a package manager. Especially, since it implements a SAT solver (libzypp) that is pretty nifty. I have heard that it managed package dependencies (cyclic, broken packages, etc.) much better than aptitude. I'm an Ubuntu user, so the above is pure speculation - but could someone answer whether the SAT solver causes the slowdown ?
- jahewson 14y ago
  The SAT solver work is great, for anyone interested check out http://www.mancoosi.org/ http://www.mancoosi.org/, there's even an annual competition for solving Linux package upgrade problems.
rwmj 14y ago
They aren't comparable and just show that the speaker hasn't used the alternative in over a decade. RPM is a packaging format like dpkg. Apt does dependency resolution like YUM/urpmi/zypper. I do a lot of packaging for both Fedora and Debian and here are my thoughts: * Building Debian packages is a horrible experience. Writing an RPM spec file is much nicer and easier. * Apt is much much faster than yum. * Using a true (NP-complete!) SAT-solver (ie. zypper) is lightyears ahead of anything Debian or Fedora are currently doing, although there's a project underway in Fedora to fork yum to use a SAT-solver.
- morsch 14y ago
  What are the practical benefits of using a SAT-solver? Is it faster? I haven't had any problems with the results of apt's algorithms, but maybe others have. When installing/upgrading stuff, the update step seems to be much slower than the other steps.
  - rwmj 14y ago
    Package upgrades are an example of SAT (the satisfiability problem)[1]. Apt and yum don't recognize this result and instead use a bunch of ad hoc rules. These often fail, when they could succeed. SAT will always find the answer, eventually, if there is one. Now the issue is that SAT is NP-complete, so it could run for a very long time before it finds a solution. But there are very good solvers which "most of the time" (meaning, basically always) find a solution in a short time. They are also open source projects[2]. There's been an existence proof (zypper) that using a standard SAT solver is possible, works, and is fast. [1] http://arxiv.org/pdf/1007.1021 http://arxiv.org/pdf/1007.1021 [2] http://www.cs.sunysb.edu/~algorith/implement/minisat/implement.shtml http://www.cs.sunysb.edu/~algorith/implement/minisat/impleme...
    - morsch 14y ago
      I understand what using a SAT-solver implies, but I haven't noticed apt failing often in practical terms. The heuristics used seem to work fine for me.
tytso 14y ago
Here's an example of why dpkg (and its associated tools) is more sophisticated than rpm (and its associated tools): While building a debian packakge, there are tools which will scan all of the binaries, determine which symbols they are using in a shared library, and compare that with a list which shows when a particular symbol was first introduced to that shared library, and use that to calculate the minimum prerequisite version for that particular shared library. This is important, because otherwise you could install a new version of a binary, and it might not work because you don't have a new enough version of its dependencies. I recently had a user who complained about this with e2fsprogs, when it used a new interface, who demanded that I bump the major version of the library (thus declaring it backwards incompatible) because this was the only way rpm and yum would automatically figure out the version dependency. I refused, and instead asked them to manually update the version dependency in their package, and pointed out that debian could automatically figure out major and minor version dependencies without needing any manual work. For an example of this text file which maps symbol versions to minimum package versions, please see: http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=blob;f=debian/e2fslibs.symbols;h=1840a2dba2f8ad6eb006fa6ce4a941a20a0bebbe;hb=HEAD http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=blob;f=debi... P.S. Because RPM doesn't do this sort of thing automatically, sometimes the only safe thing you can do to make sure there aren't any overlooked version dependencies is to download the latest versions of all of the packages installed on your system, and run the command rpm -Fvh *....

by joshAg 14y ago

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 ago
Does RPM have any advantages?
- Spidler 14y ago
  Better 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 ago
  As a developer, I'm actually able to easily package stuff with rpm. creating .debs is stupidly frustrating
  - vidarh 14y ago
    Whenever 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.

strictfp 14y ago

I'm just a casual user, and I didn't really notice any difference between deb and rpm. But I did notice a significant difference between apt and yum. Yum was much slower and less clever in figuring out dependencies. I've had yum uninstall unrelated programs sharing libs with the one being uninstalled. It seems like apt(itude) has more advanced resolution algos built in. Plus more is avail as deb than rpm, no need for manual download via websites.

ableal 14y ago
I'll second this. It is also my experience, having used both Fedora and CentOS (2002-2008) and Ubuntu (2004 to now).
hessenwolf 14y ago
For me apt is yum, so I've never bothered to check whether yum is apt. I'll get my coat and leave this comment thread now.

carlesfe 14y ago

Do rpm-based managers still work out the package dependences incorrectly, take a long time to download the headers, and generally break constantly? Honest question, I haven't used an RPM-based distro since a couple of years ago. Last was opensuse 11, then fedora 3. rpm is a pretty great format, but the frontends are not very good. apt, on the other hand, rocks, and aptitude rocks even more.

chalst 14y ago
Note that both apt-get and aptitude, together with dpkg, are part of APT (advanced packaging tool), which is the suite of tools handling .deb packages. While I'm at it, neither apt-get nor aptitude are simply front ends to dpkg - both have fairly complex (and different) policies for how to handle dependency conflicts, etc, while dpkg makes you do everything by yourself. See http://superuser.com/questions/93437/aptitude-vs-apt-get-which-is-the-recommended-aka-the-right-tool-to-use http://superuser.com/questions/93437/aptitude-vs-apt-get-whi...

bad_user 14y ago

I haven't noticed much of a difference between apt and rpm, but the one thing that keeps me on Debian and Ubuntu (versus other distributions or OS X) is the huge and properly maintained Debian software repository that has no competition.

wtracy 14y ago

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.

lucian1900 14y ago
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.
- ch0wn 14y ago
  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.
  - raverbashing 14y ago
    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
- toyg 14y ago
  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".)

retube 14y ago

I haven't used rpm for a while having left redhat for ubuntu years back so this may be out of date: but certainly at the the time rpm was famous for "dependency hell" and deservedly so - almost everything I tried to install was a circular nightmare of incompatible dependencies. To the extent that i'd have to give up or resort to compiling from source. OTOH, apt was an absolute dream. It just worked. It'd fish anything required out of remote depository. There were never any version incompatabilities. I've never once had a failed install. On moving to apt I never looked back and would never use rpm again: indeed for me apt was Ubuntu's "killer feature".

lutusp 14y ago
> I haven't used rpm for a while having left redhat for ubuntu years back so this may be out of date: but certainly at the the time rpm was famous for "dependency hell" and deservedly so ... True, but since then yum has taken over from rpm, and yum automatically resolves dependency issues. Just saying. All major distributions have tools that avoid dependency hell, in one way or another. The bad old days of rpm trying to sort things out on its own -- and failing -- are gone, and good riddance. > On moving to apt I never looked back and would never use rpm again. Yes, but it's important to point out that Red Hat / Fedora users don't use rpm any more either.
vidarh 14y ago
apt is not the equivalent of rpm. dpkg is the equivalent of rpm. And dpkg is equally dumb (both of them "by design" - it's not what they're meant to do) But Yum and Apt as well as other tools have been available to do automatic dependency resolution on RPM based distros for many years - I believe at least apt-rpm predates Ubuntu.

eikenberry 14y ago

It was never about the packing format (dpkg, rpm) nor about the management system (apt, yum)... it was ALWAYS about the number of packages and how well integrated they were and still are. Debian based distros still have the upper hand here as everything belongs to the official distro and is packaged as part of the whole system. RPM based distros all seem to go for the idea of the smaller core set of packages with other repositories filling out other parts of the ecosystem. It just doesn't work as well.

sandGorgon 14y ago

I'm actually surprised that this is the case. I dont know if yum's slowness (as a by product of its implementation) is one of its shortcomings, but I always presumed that it was more sophisticated as a package manager. Especially, since it implements a SAT solver (libzypp) that is pretty nifty. I have heard that it managed package dependencies (cyclic, broken packages, etc.) much better than aptitude. I'm an Ubuntu user, so the above is pure speculation - but could someone answer whether the SAT solver causes the slowdown ?

jahewson 14y ago
The SAT solver work is great, for anyone interested check out http://www.mancoosi.org/ http://www.mancoosi.org/, there's even an annual competition for solving Linux package upgrade problems.

rwmj 14y ago

They aren't comparable and just show that the speaker hasn't used the alternative in over a decade. RPM is a packaging format like dpkg. Apt does dependency resolution like YUM/urpmi/zypper. I do a lot of packaging for both Fedora and Debian and here are my thoughts: * Building Debian packages is a horrible experience. Writing an RPM spec file is much nicer and easier. * Apt is much much faster than yum. * Using a true (NP-complete!) SAT-solver (ie. zypper) is lightyears ahead of anything Debian or Fedora are currently doing, although there's a project underway in Fedora to fork yum to use a SAT-solver.

morsch 14y ago
What are the practical benefits of using a SAT-solver? Is it faster? I haven't had any problems with the results of apt's algorithms, but maybe others have. When installing/upgrading stuff, the update step seems to be much slower than the other steps.
- rwmj 14y ago
  Package upgrades are an example of SAT (the satisfiability problem)[1]. Apt and yum don't recognize this result and instead use a bunch of ad hoc rules. These often fail, when they could succeed. SAT will always find the answer, eventually, if there is one. Now the issue is that SAT is NP-complete, so it could run for a very long time before it finds a solution. But there are very good solvers which "most of the time" (meaning, basically always) find a solution in a short time. They are also open source projects[2]. There's been an existence proof (zypper) that using a standard SAT solver is possible, works, and is fast. [1] http://arxiv.org/pdf/1007.1021 http://arxiv.org/pdf/1007.1021 [2] http://www.cs.sunysb.edu/~algorith/implement/minisat/implement.shtml http://www.cs.sunysb.edu/~algorith/implement/minisat/impleme...
  - morsch 14y ago
    I understand what using a SAT-solver implies, but I haven't noticed apt failing often in practical terms. The heuristics used seem to work fine for me.

tytso 14y ago

Here's an example of why dpkg (and its associated tools) is more sophisticated than rpm (and its associated tools): While building a debian packakge, there are tools which will scan all of the binaries, determine which symbols they are using in a shared library, and compare that with a list which shows when a particular symbol was first introduced to that shared library, and use that to calculate the minimum prerequisite version for that particular shared library. This is important, because otherwise you could install a new version of a binary, and it might not work because you don't have a new enough version of its dependencies. I recently had a user who complained about this with e2fsprogs, when it used a new interface, who demanded that I bump the major version of the library (thus declaring it backwards incompatible) because this was the only way rpm and yum would automatically figure out the version dependency. I refused, and instead asked them to manually update the version dependency in their package, and pointed out that debian could automatically figure out major and minor version dependencies without needing any manual work. For an example of this text file which maps symbol versions to minimum package versions, please see: http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=blob;f=debian/e2fslibs.symbols;h=1840a2dba2f8ad6eb006fa6ce4a941a20a0bebbe;hb=HEAD http://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=blob;f=debi... P.S. Because RPM doesn't do this sort of thing automatically, sometimes the only safe thing you can do to make sure there aren't any overlooked version dependencies is to download the latest versions of all of the packages installed on your system, and run the command rpm -Fvh *....