Would someone mind giving a brief overview of why apt is better than rpm (or why someone might think this?)?
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=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 *....
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.
But I agree with the yum sentiment, it really looks bad when compared to other solutions that existed: urpmi, apt-rpm, etc
(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".)
I'll get my coat and leave this comment thread now.
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.
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.
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.
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 [2] http://www.cs.sunysb.edu/~algorith/implement/minisat/impleme...
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 ?
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.
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-whi...
A good StackExchange thread: http://unix.stackexchange.com/questions/634/what-are-the-pro...
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.
I agree, though, as much as the RPM spec files are horrible, it's still overall simpler.