Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

It appears that the major package managers are (in no particular order) apt, yum, and pacman. But when it comes down to it, what is the difference? My understanding is that you can use any of them on any distribution, although every distribution appears to favor one over the other.

So, my questions are: What are the core differences between the major package managers? Why should I consider one over the other?

share|improve this question
1  
do you just want the 'package manager' argument? simply put most of the package formats/managers don't have that much a difference other than syntax. It's the philosophy that matters. Arch for example is a rolling distro, and amongst its philosophy is follow upstream, and it doesn't have seperate -dev packages. It's not that you can't do these things with e.g. apt, and deb, but they don't. –  xenoterracide Aug 21 '10 at 1:41
    
I want to avoid a "X is better than Y because I said so" - I want to know the technical reasons as to why X is better than Y or X is worse than Y at performing some task. Is syntax the only difference? –  Thomas Owens Aug 21 '10 at 12:03
    
"My understanding is that you can use any of them on any distribution" Not really. You can only use yum with rpm-packages, apt with deb or rpm packages (the latter is possible via apt4rpm which is a "port" of apt for rpm) and pacman with pacman-packages. And then you still need a package repository for the given package manager which has packages for your distro. –  sepp2k Aug 21 '10 at 12:36
    
no there are more differences than that... but there's no silver bullet (like which programming language is best). Yum is better at X while Apt is better at Y and Pacman is better at Z. Which is better is subjective, which is better at X may not be. –  xenoterracide Aug 22 '10 at 11:41
    
xenoterracide: That's what I'm looking for. I'm looking for something that says for a task X, package manager Y is best because of Z, repeated for all major tasks that a package manager is used for. –  Thomas Owens Aug 22 '10 at 15:18

3 Answers 3

well it's basically about the kind of packets they deal with (apt - deb; yum - rpm; pacman - tar.gz) where these packaging systems are a bit different themselves... then there's the question of how well they deal with dependencies (pretty important)... and of course - options they provide and how they can present the data about packages being installed... I would say these would be some of the major differences...

share|improve this answer
3  
"pacman - tar.gz" is a bit misleading. It makes it sounds as if any tar.gz-file would be a valid pacman-package. –  sepp2k Aug 21 '10 at 12:33

Package managers can be divided into two main categories:

  1. Binary package managers: the software is built on some remote machine and you only get the result of the compilation. The most popular (only?) formats being deb (apt) and rpm (yum).

  2. Source package managers: the software code source is retrieved directly and the compilation is done locally. Some source package managers being emerge, pacman, yaourt, slackpkg, pkgng from BSD, Mac Ports, Homebrew, pip (Python), gem (Ruby), etc.

The main advantage of binary packages is that the installation time is greatly reduced if your internet bandwidth is high enough. Reproducibility is also better as to one version of the package will always correspond to one and only one binary.

The disadvantages are the package size (several times bigger than the source code) and the system rigidity: unlike Windows, binaries on Linux usual embeds hard-coded paths and re-locable binaries (binaries that you can move around) are difficult to generate. I.e. binary package manages usually only work in /usr.

To give you an idea of the different between sources and binaries, the Debian archive is currently a bit more than 1Tb but only 72Gb for the sources! One architecture, for instance amd64, being about 95+92=187Gb (2.5 bigger (1)).

Another problem with binary packages is the fixed compilation flags: some optional features may be disabled in the system package, some modern CPU extensions may also be disabled for compatibility reasons...

A debatable point is the tendency for binary package managers to provide older releases. Indeed, mainly source package managers are providing the latest update for every package soon after each release. However, binary packages tends to be extensively tested before reaching the repositories (after all, they have to compile successfully for all the architectures!).

To help you choose, a common pattern is to use a binary package manager for servers and boxes for which one does not want to spend a lot of time in the configuration process. For a development machine used by a "power user" and where you will need bleeding-edge libraries, source package managers tend to be used more frequently.

(1) 95Gb+92Gb is the sum of the amd64 packages and the "all" packages which are the architecture independent files (multimedia resources, fonts, documentation, etc.)

share|improve this answer

The package managers you cite are really just a choice of front-ends to an underlying packaging system. For example, yum is a front-end to RPM, and others exist (smart, zypper, apt4rpm, and so on). Similarly, the average DPKG-based system has two or three package managers by default (Synaptic, Aptitude, apt-get, dselect, and so on). I don't know enough about Pacman to comment there.

The front-end is really not all that interesting - there's a degree of dependency resolution it needs to handle, but the really "difficult" part of package management comes from the underlying package format.

Again, I can't comment on Pacman, but between RPM and DPKG, It's RPM which has a tougher job - you can define extremely complex relationships in your RPM package, which the resolver needs to somehow handle, and a single slip-up in your package definitions may cause misery down the line. DPKG is a much simpler format as far as dependency information is concerned, since you can only define two things - package names and versions - whereas with RPM you can do complicated things like versioned symbols in dependencies, and so on.

So, to answer your question, the choice between managers within a single format is personal taste only (I mostly use aptitude). The choice between formats is one of how fine-grained a control you want (and, ironically, how much complexity you want that control to introduce into your packaging).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.