9

A discussion from this post made me curious of differences between Debian and Arch package management. Also, people tend to say that Arch is very light-weight, so I wonder what that has to do with package management. Is it maybe because Debian treats Recommends as hard dependencies by default?

Can you also mention the flexibility/power between the two package managers: which of the two lets you do more.

I'm aware that some features available on a Debian package management system would be irrelevant on an Arch system, since Arch has a single Suite and Debian has multiple (e.g. APT pinning and advanced dependency handling come to mind), so please compare features that are applicable to both systems (i.e. assume that for Debian, I only use unstable).

1
  • NOTE: By Debian package management I'm referring to APT, aptitude, and dpkg. I'm not familiar with Arch tools, so I don't know if there's anything other than Pacman.
    – tshepang
    Mar 25, 2011 at 17:14

4 Answers 4

Reset to default
7

I just use arch regularly since a few weeks and am no expert on the subject so this answer is by no means exhaustive, just a few points I have noted about the "flexibility/power":

  • This is just an impression but pacman seems more modern and simple in its design/architecture. At least there is far less tools to deal with. While I don't know of apt source code, I just happened to look at libalpm code (the underlying library to pacman) to make a very simple patch, and it seems clean and easy to understand.

  • It is also very fast (due to optimization and also probably by caring about few things (see below)). The last release (pacman 3.5, a few days old) tried to improve performance by reducing the number of involved database files.

  • While arch is oriented towards the use of binary packages, it also has advantages when building packages from source, with a build system similar to BSD's ports (ABS).

  • It's very easy and quick to create packages, just a few lines in a PKGBUILD file and its done, no need to deal with control/rules/copyright/changelog/whatever like with Debian packages. And in a few clicks on a web ui your package is shared with everyone on AUR (Arch User Repository).

Things I get in Debian and not in arch :

  • Triggers/hooks (what makes apt update the icon cache, the mandb or whatever just by looking at where the package install files, with no need for the packager to do anything) (seems there are plans to implement this).

  • debconf (no big deal and by the way by forcing me to do things manually it forces me to know what exactly is done) and proper handling of new config files (I would at least like pacman to know when a config file in a new package version is different of the installed one because it was changed in the new version or because I modified it locally).

  • package signing (seems it's being worked on).

For arch being light, the only real reason is that it comes with few packages installed by default and you're encouraged to add what just you need, so probably not installing optional dependencies by default is inciting users to install avoid bloat.

8
  • I can't parse this: but I can do without it and by the way know what I do better. There is also a typo on the last sentence.
    – tshepang
    Mar 27, 2011 at 14:52
  • What language is the pacman package manager written in? Does it have low level and high level package management functionality similar to dpkg/apt, and if so, what are they called?
    – Faheem Mitha
    Mar 27, 2011 at 15:10
  • @Tshepang: sorry, non-native english speaker here. I meant "this is not a big deal for me to not have this functionnality (debconf) and by forcing me to do things manually it forces me to know what exactly is done".
    – gentledevil
    Mar 27, 2011 at 17:27
  • @Faheem Mitha: Pacman is written in C, and is a frontend to libalpm, which handles both "high-level" and "low-level" package management.
    – gentledevil
    Mar 27, 2011 at 17:32
  • @zanko: I'm not a native speaker either. All I wanted you to do is make the sentence clearer, and not in a comment, but on the post itself. BTW, the typo I mentioned is optionnal. I could edit the post myself, but I thought you might as well fix it together with the clarification part.
    – tshepang
    Mar 27, 2011 at 17:41
6
+50

I started my Linux journey with Ubuntu lucid, and currently use Arch. I've written a handful of Arch packages, and I'll say its far easier than writing Debian packages. But, I'd like to point out to @gentledevil that Arch does have a hooks system for packages, known as an install file.

Basically, its named ${pkgname}.install, and contains a few functions for pre/post install/removal/upgrade; just place your font-cache updates in that and so on and it works just about the same as the Debian hooks.

Also, I notice you mentioned 'pinning' an application using debian package management tools; Arch's pacman has that built-in as well, /etc/pacman.conf accepts a number of settings, including IgnorePkg =, which will prevent upgrades to any packages listed after the equals (space-delimited)

1
  • 1
    Also, while its not a repo package, you can use the powerpill wrapper for pacman to have parallel downloads of multiple packages, so instead of pacman -S libfoo libbar libbaz downloading each package one after the other it would instead download all three simultaneously, greatly increasing upgrade speeds for better connections.
    – hanetzer
    Jul 11, 2014 at 12:46
-1

Before I go too far, study the Pictorial Linux Timeline

To understand the differences in Package Managers, you must understand the philosophies of the the OS'es pictured above

Three Major Parents

  1. Redhat, Now Fedora - Package Manger - RPM, short for Redhat Package Manager, command line rpm
  2. Slackware - Package Manager - tgz, ordinary zipped files. Although these are just compressed files, the were built by Slackware upstream and placed in a repository, sometimes referred to as a port
  3. Debian - DEB, short for Debian, it's command line tool is Aptitude or Apt

These Parents are mothers and fathers to most of the distributions we know today. The idea/concept of a Package Management System was derived or shared in some form or fashion. Regardless, all these parents are binary distributors, meaning that a program is packaged and decided on by a 3rd party, then stored in a repository, and consumed or installed by the user base.

3 Minor Parents

  1. Linux From Scratch - Source Based, no package manager.
  2. Gentoo - Derived from Linux from Scratch. This distribution is essentially Linux from Scratch plus a package manager, called Portage/emerge
  3. SourceMage - Package Manager Sorcery

These Parents are minor because their userbase trades speed and ease of installation with power and ease of configuration. Each package is downloaded and compiled from scratch, using variables and configuration files.

The Bridge

Arch was created as a bridge between a binary distribution, like one of the 3 Major Parents, and a source based distribution like one of the 3 Minor Parents. As such, it receives status as a parent in the timeline, because no other parent provided this functionality. Pacman has the flexibility to allow a user to install a binary package from an official repository, or a custom built package using the Arch Build System. This concept provides a balance between the power the minor parents give with the ease of install that the major parents give.

In my opinion, it isn't the package manager that shows the power of a system, as all package managers do the same task, which is to manage and maintain a healthy system. As such, the system you use should be determined by factors such as:

  • User Level: Someone new to linux should start with a Major Parent, whereas someone technically proficient will find a balance.
  • What you want to do with your system: Running a LAMP server with attached users is totally different than running a desktop PC for web browsing and e-mail reading.
  • Comfort Level: User level not withstanding, if you are technically proficient, but don't want to spend a weekend compiling a system, you will choose a major parent, regardless of whether everyone you know chooses something else.
4
  • This is more focussed on the geneaology of the distributions, rather than a comparison of pacman and Debian's package management tools...
    – jasonwryan
    Jul 16, 2014 at 18:14
  • @jasonwryan That's the point, as all package managers accomplish the same task, i.e. emerge packagename is the same as sudo apt-get install packagename.
    – eyoung100
    Jul 16, 2014 at 18:32
  • At that level, yes; but that entirely misses the point of the question, ie., what differentiates pacman from {apt,aptitude}.
    – jasonwryan
    Jul 16, 2014 at 19:01
  • @jasonwryan I answered that in The Bridge section. Other than that, there is no difference. The only differences are semantic, i.e one command versus another. If the OP is looking for semantic differences, there is a manual for that.
    – eyoung100
    Jul 16, 2014 at 19:57
-3

This is by no means a complete or exhaustive answer - the posters before me already gave some very good points, I'd just like to add my 2 cents. Another thing - I never really got used to apt/dpkg. It always seemd over-complex to me, I'm really most comfortable with yum/rpm.

pacman is very easy to use, which is a pro and a con - you can learn to use it (package building aside) in a single afternoon - it uses mostly intuitive and complete package management features, but - and this is a big but - it is extremely inflexible.

If the designers did not think of a feature beforehand, you're screwed.

A few examples: there is no native versioning in pacman. If you wish to downgrade a package version - you have to download that particular package version, and use the -U (upgrade) option to install from file. It is very much geared towards always using cutting edge packages on your system.

There is no real internal cache cleaning/complete rebuild. If (due to a network issue) a package download was corrupted, e.g during -Syu, the error message, while accurate, will not be of much use - it will not pinpoint the corrupt package even with "full" verbosity and debug turned on, and no amount of -Syyc will really clean the cache and redownload the packages. The good news is that -Sc will let you know where the downloaded packages are so you can simply remove the offending one (if you can figure out which one that is) or all of them and restart -Syu.

pacman integration with dkms is also somewhat problematic - while installing a new kernel I kept having errors from dkms. Using dkms build && dkms install against the new kernel worked without a hitch, yet pacman would offer no information whatsoever why dkms failed during the kernel upgrade (I suspect it never passed the correct path of the new kernel, and just let dkms use the default (current running) kernel but with wrong version).

Another anecdote about it's inflexibility - as stated, I'm used to rpm/yum. If I have a file on my system and I wish to know which package owns it, I can run yum provides /path/to/file and get ALL packages that can put it there - even if none of them is installed. If the file was placed manually, and now I wish install a package - it will renamethe new one(add extension .rpmnew), and let me choose what to use.

pacman simply errors out that a file already exists, but with a completely irrelevant error message - it complain of conflicts between the file "true" owner and the currently installed "filesystems" package, as if it is also an owner of the same file. Also it's mostly geared towards local installed information - trying to gain information (such as file lists and ownership) of packages not yet installed is less intuitive.

Simply put - it is not as mature as yum, and probably dpkg, which lends to it's ease of use as well is relative inflexibility.

7
  • 2
    Short of a comprehensive non-answer, there are a number of points that you raise that really are a product of an unfamiliarity with pacman. For example pacman -Qo $file will tell you what package owns $file. Also, your whole answer is a strawman as the OP explicitly asked for differences between Arch and Debian--yum has nothing to do with it...
    – jasonwryan
    Jul 12, 2014 at 20:34
  • which is why I explicitly disclosed that fact in the beginning of my answer. as for the -Qo $file - have you ever tried that for a package not yet installed?
    – Dani_l
    Jul 12, 2014 at 20:59
  • 1
    There is no point trying it for a non-installed package; there are other tools for that. And disclosure doesn't mitigate the fact that you haven't answered the question: a "comparison" between yum and pacman is not the same as the differences between Debian's and Arch's package managers.
    – jasonwryan
    Jul 12, 2014 at 21:21
  • @jasonwryan Of course there is a point. Just because you don't see the need to figure out which package might own a file even if it's not yet installed, doesn't mean such a need doesn't exist. That was the point. As for other tools - are they on a need to know basis? pacman is the package manager. Regarding your main point - I might have completely misread the question, but I assumed it be about a lightweight PM vs. a more complex PM. I assume apt/dpkg to be at least as complex as yum/rpm, feature wise.
    – Dani_l
    Jul 12, 2014 at 21:40
  • My point is that you are answering a question about comparing apples with oranges by comparing your limited understanding of apples with pears. And yes, you have completely misread the question...
    – jasonwryan
    Jul 12, 2014 at 21:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .