As I am sure many of you are aware I have tried over twenty different Linux distributions, many of which use different package managers to one another. Each package manager has several different characteristics, all of which influence my decision to use them and hence also my decision to use the respective Linux distribution(s) on which they are used for package management. In this comparison I will compare the following package managers (note, each package manager’s long name is hyperlinked to their respective section):

  • Advanced Packaging Tool (APT), the default package manager of Debian and its various derivatives. I will also discuss the related package managers aptitude and Synaptic in this section.
  • Dandified Yum (DNF), the default package manager of Fedora ≥22 and its up-to-date derivatives (e.g., Chapeau and Korora) and the successor to yum.
  • Entropy, the default package manager of Sabayon Linux.
  • pacman, the default package manager of Arch Linux and its derivatives.
  • Portage, the package manager of Gentoo Linux and its derivatives such as Calculate and Sabayon.
  • Yellowdog Updater, Modified (yum), the default package manager of CentOS, Fedora ≤21 and the predecessor of DNF.
  • ZYpp (zypper), the default package manager of openSUSE and its derivatives.

with respect to the following areas:

  • Beginner-friendliness. Does it have an easy to understand and remember syntax? Does it have a high-quality of free documentation? Does it have an officially-supported graphical user interface? If so, is this GUI intuitive and easy to use?
  • Customizability. How much customization of installed packages and the options for this package manager are allowed?
  • Development: How easy is developing packages for this package manager?
  • Features. Does this package manager allow users to abbreviate commands? Does it allow users to skip confirmation checks? Does it include search functions? Does it show users detailed information about the packages when asked? Does it support local installs? Can it install packages from a specified URL? Does it support installing the dependencies of a target package only? (e.g., apt-get build-dep) Does it support installation from source code and binary packages? Does it support wildcards?
  • Speed. This is something that will be based on research, along with one test. The test is I will reinstall the vim package (reinstalling so to ensure the time measured is only the time taken to install the package and not the time to download the package, download and install its dependencies, etc.) on a Virtual machine. This process I will time using the time command. For example, for pacman I ran: root #  time pacman -S vim –noconfirm. If you can think of a more reliable test as to their speed (that ignores download times), that can be used for each of these package managers (that is, if it requires a command other than time, it is probably best to check whether I can install the program that provides said command on all the relevant distributions) and that does not take a giant chunk of time to do (that is, if you suggest I reinstall several packages on each platform, time them and average the result out, I probably will not be sold as it sounds tedious), I am more than willing to hear it and if you wish I will even add an Acknowledgements section to this post and give you due credit in it. See the Contributing page for details on how to contact me with this information.

Glossary

Debian Packages

Debian packages are software packages with the file extension .deb. They are archives formed with the ar utility, inside them are three files:

  • tar archive called data, that is optionally bz2, gz, lzma or xz-compressed. It contains the installed files.
  • tar archive called control, that is optionally compressed with any of the aforementioned algorithms and it contains package metadata.
  • debian-binary text file that contains the deb format number, the latest is presently 2.0. They are probably the single most popular type of Linux binary package out there, as they are used by each of the three most popular Linux distributions, according to DistroWatch (Debian, Linux Mint and Ubuntu).

dpkg

dpkg is a low-level package management tool that installs, removes, upgrades and provides information about Debian packages. dpkg was first developed by Ian Murdock in 1994 and is written in C, C++ and Perl.

RPM Packages

The RPM Packages are the binary package format that the RPM package manager works with. They have the .rpm file extension. They are archive files, you can extract their contents with the bsdtar -xf $package.rpm command, where $package is the package’s name, without the .rpm file extension. There is also a source code version of the RPM Package format, with the file extension .src.rpm.

RPM Package Manager

The RPM Package Manager1 is a low-level package management tool that installs, removes, upgrades and provides information about RPM packages. Its initial release was in 1997.

APT

The Advanced Packaging Tool (APT) is the default front-end for the dpkg package manager used by Debian-based systems. See what APT does is it performs dependency resolution, repository management, and assorted other higher-level functions while dpkg is what actually installs and removes packages. So in essence what APT does for dpkg is it gives it some intelligence; package management with dpkg by itself is not an experience I would like to have as you would have to do just about everything yourself. It is the eldest package manager mentioned in this review and was first developed in 1998. APT is written in C++ and Bash script.

Beginner-Friendliness

APT was the first Linux package manager I ever used and I started using it on Ubuntu, so I may be biased towards saying it is beginner-friendly, although I will admit I think there are more beginner-friendly package managers out there, like DNF, yum and zypper. See APT has a somewhat confusing syntax, as you do not just run root #  apt [action] [option(s)] [target(s)] rather there are five distinct commands for APT, each with their own options, actions and permissible targets: add-apt-repository, apt, apt-cache, apt-config and apt-get. apt-get is used to install, remove and upgrade packages and update local index files for enabled repositories. apt-cache is for searching and dealing with the cache and metadata in it. add-apt-repository is used for managing repositories, while apt-config is for editing configuration files from the command-line. apt itself, on the other hand, seems to be capable of performing select actions from apt-cache, apt-get and apt-config.

Despite this APT has several more beginner-friendly front-ends such as the ncurses-based textual program, aptitude, that is run from within a terminal and the GTK-based graphical front-end Synaptic. Here is the aptitude man page in HTML. My experience with both front-ends is fairly limited as I was willing to just stick to APT and the Ubuntu Software Center (another graphical front-end for APT, as its name suggests it is used by Ubuntu and select derivatives thereof) during my three years using Ubuntu as my distro. Overall I would rate APT as 5-7/10 for beginner-friendliness as while its syntax can get confusing when you are just beginning to use it, there are two perfectly adequate, more beginner-friendly front-ends for it available.

Customizability

APT being a binary package manager, has limited customizability when it comes to the binary packages it installs. By this I mean these binary packages have already been compiled so it is impossible for users to specify desired features for the package to have. There is one way one can customize installed packages that I know of: by downloading the corresponding source code package for each installed package one wishes to customize and editing the files used to build the package. A guide on how to do this can be found at the Debian Wiki. It essentially consists of running user $  apt-get source $package, changing into the package’s directory, modifying the required files, getting the build dependencies with root #  apt-get build-dep $package, then building the package with user $  debuild -b -uc -us. and finally installing it with root #  dpkg -i ../$package-$version.deb The most important file for one to customize, in terms of changing the features the package is built with, is the rules file in the debian/ folder.

Development

Debian package development (an introduction to Debian packaging can be found here at the Debian Wiki) is more complicated than developing Arch and RPM packages and writing ebuilds for Gentoo packages, in my opinion. See first of all, Debian packages are not built based on the contents of a single file plus files referred to by said single file, as is the case for ebuilds and PKGBUILDs, rather Debian packages are built based on the contents of an entire directory. In the top-level of the directory there is the package’s upstream source along with a debian/ subfolder, which contains several components that are specific to the Debian package being built. Its structure is as follows:

- debian/
-- changelog
-- compat
-- control
-- copyright
-- rules
-- source/
--- format

the contents of the changelog and copyright files I think are pretty obvious, so I will skip them and just mention what is in the compat, control and rules files. The compat file is a file that contains nothing but the number nine (9) in it, as it is supposedly a “magic number”. The control file contains most of the package’s metadata like its description, name, version, dependencies, etc. while the rules file contains the build instructions for the debuild command to follow, in order to build the Debian binary package. Frequently, a single upstream package will be split up into over three different Debian packages, each with different suffixes (most commonly debug, dev and doc) and/or prefixes (most commonly lib). This package splitting, from my understanding, is designed to give users greater freedom over their installed packages. If they want debugging symbols, development features, documentation or the package’s installed libraries they can install them separately, while if they just want basic functionality for the package in question they can install the base package and not install these extras, hence saving space.

Features

APT, by default, installs binary packages, with the file extension .deb, although an RPM rewrite for APT exists called APT-RPM that uses binary packages with the .rpm file extension. APT-RPM is only used by one Linux distribution I have personal experience with, PCLinuxOS and I have personally noticed no syntactic, performance or other difference between it and APT, based on my limited experience with it. APT can also be used to build and install software from source code packages (which are provided by the APT src repositories). Its enabled repositories are listed in /etc/apt/sources.list, here is an example one taken from my Debian 8.3 VM:

deb http://debian.mirror.digitalpacific.com.au/debian/ jessie main
deb-src http://debian.mirror.digitalpacific.com.au/debian/ jessie main

deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main

# jessie-updates, previously known as 'volatile'
deb http://debian.mirror.digitalpacific.com.au/debian/ jessie-updates main
deb-src http://debian.mirror.digitalpacific.com.au/debian/ jessie-updates main

. One disadvantage of APT, as opposed to DNF, yum or ZYpp, is that it cannot be used to download a package and install it from a specified URL. Instead, if one wishes to install a .deb package from a URL one has to run something like:

user $  wget $URL
user $  sudo dpkg -i $package.deb
user $  sudo apt-get -f install

where $URL is the URL you wish to install the Debian package from, while $package is the package’s name, without its .deb file extension. The third of these lines installs any missing dependencies that are available from enabled repositories (listed in /etc/apt/sources.list) and then will install the $package.deb file, if line 2 failed to, due to missing dependencies. I have heard that later releases of APT may be able to install local packages and do dependency management without dpkg having to be explicitly called. In other words, these later releases of APT may be able to install a package from URL with just two commands, namely:

user $  wget $URL
user $  sudo apt-get install $package.deb

. One feature of APT that can be handy is that it supports the use of wildcards, e.g., root #  apt-get install lua5.2* should install all packages with the lua5.2 prefix. It supports the installation of package groups too. To list available package groups I suggest you install the tasksel if it is not presently installed (via issuing root #  apt-get install tasksel) and run user $  tasksel –list-tasks. Then to install the package group you run root #  apt-get install $group^, where $group is the package group in question. One-click installs are supported by APT, on Ubuntu at least.

Speed

Running root #  time apt-get install -y –reinstall vim gives:

Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/953 kB of archives.
After this operation, 0 B of additional disk space will be used.
Can't set locale; make sure $LC_* and $LANG are correct!
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_AU:en",
        LC_ALL = (unset),
        LANG = "en_AU.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
(Reading database ... 229043 files and directories currently installed.)
Preparing to unpack .../vim_2%3a7.4.488-7_amd64.deb ...
Unpacking vim (2:7.4.488-7) over (2:7.4.488-7) ...
Setting up vim (2:7.4.488-7) ...

real    0m2.783s
user    0m1.076s
sys     0m0.392s

so it took 2.783s to reinstall Vim. I think this figure is fair enough, as it is the third fastest package manager reviewed in this comparison.

Basic Usage

Table 1: Basic Usage of APT
Action Command1 Description
Add a repository
root #  add-apt-repository $repository
Add APT repository, $repository.
Build package from source
root #  apt-get source --compile $package
Building $package from source code.
Install build dependencies
root #  apt-get build-dep $package
Install required build dependencies for the target package ($package).
Install package
root #  apt-get install $package
Install the target package ($package) and all runtime dependencies.
Remove package
root #  apt-get remove $package
Remove the target package ($package) and all runtime dependencies not required by other installed packages.
Search for keyword
root #  apt-cache search $package
Search package name and description for provided regex. Pass option --names-only to search only package names for regex.
Upgrade all packages
root #  apt-get update && apt-get upgrade
Update index lists and upgrade all installed packages.
1: Note: in this table I use the short-hand notations $package and $repository to refer to the target package(s) or repository, respectively, that the user wishes to perform the mentioned action on.


DNF

Dandified Yum (DNF) is a rewrite of yum that’s major distinguishing feature, from its predecessor, is the fact it uses ZYpp’s libsolv library for dependency resolution and hence has performance advantages over yum. Despite this DNF is very similar to its parent, as it has an almost identical syntax, is written in Python and it serves as a front-end (for dependency resolution, repository management, etc.) for the RPM package manager. DNF has replaced yum as the default package manager of Fedora since the release of Fedora 22 in May 2015. CentOS is likely to follow suit sometime in the future.

Beginner-Friendliness

DNF is more intuitive than APT as there is just a single command that calls it, dnf. Its syntax is simple, for example root #  dnf install octave should install GNU Octave, while root #  dnf remove octave should uninstall it. Fedora and most of its derivatives use PackageKit front-ends such as Apper (for Qt-based desktop environments such as KDE) and GNOME Software, for graphical package management, both of which run DNF in the background. Overall I would rate DNF as 8/10 for beginner-friendliness. Its basic syntax is:

root #  dnf [action] [option(s)] [target(s)]                                                               (1)

for more details see its man page.

Customizability

As with APT, DNF is primarily a binary package manager, so by default there are not many customizations that can be done to existing packages. Like with Debian packages for APT, however, a single upstream software package is often split into multiple smaller RPM packages, with each RPM package providing different functionalities of the upstream package. So this allows for some customization of installed packages, as users that just want basic core functionalities of the upstream package can just install the base package, while those that want to do development or debugging with the package can install the respective package providing said features.

DNF, however, is capable of downloading .src.rpm packages, which can be extracted (several ways this can be done, my personal preference as it works on any Linux platform is user $  bsdtar -xf $package.src.rpm), modified and rebuilt if the user really wants to customize the package, like adjust its configure options. I would personally recommend that if you wish to do this and you are not familiar with the process of building RPM packages that you read this Fedora Wiki article on it.

Development

As DNF is just a command-line front-end for the RPM package manager, package development is the same as it is on other Linux distributions that use RPM packages. Follow this Fedora Wiki guide on building RPM packages. Alternatively for most packages, you can also use the Open Build Service (OBS) to build the package, which affords one the ability to more easily distribute the packages to others should you wish to. Here is an OBS tutorial, further details on the OBS and its limitations can be found in the ZYpp Development section. It is also possible to do package development using the Copr, which I had never used until I wrote this post. I used it once, to get some info for you, my readers, on it and I must say it is like the OBS but it seems more flexible in some areas but less flexible in others.

Copr is an online tool that is specific to Red Hat Enterprise Linux and Fedora as it can only be used to build packages for these two distributions. It can take a spec file as its input, along with the required sources (which are taken from a git repository, like a GitHub repository, that you specify to it), or it can take a .src.rpm, but regardless of its sources it will build an RPM package for the platforms specified to it. These packages are then available from an online repository created and hosted by the Copr. Unlike the OBS, however, and this is where the Copr really shines in my books, it can provide packages Internet access during the build, hence making Atom package development for Fedora far easier. The only limitation imposed on Copr packages that are not imposed on OBS packages is that Copr packages must be free and open-source, while the OBS provides some proprietary packages including Spotify.

Features

DNF can be used to download and then install RPM packages from a specified URL too, which is a feature it has inherited from yum. For example, to install Atom 1.5.3 on a 64-bit Fedora system from the official RPM binary one would run (this command will not prompt the user before downloading and installing this package):

root #  dnf install -y https://github.com/atom/atom/releases/download/v1.5.3/atom.x86_64.rpm

. I ran this command on a Fedora 23 VirtualBox VM to test it out and here was its output:

Last metadata expiration check performed 0:05:36 ago on Mon Feb 15 16:25:44 2016.
Dependencies resolved.
================================================================================
 Package      Arch           Version                 Repository            Size
================================================================================
Upgrading:
 atom         x86_64         1.5.3-0.1.fc21          @commandline          55 M

Transaction Summary
================================================================================
Upgrade  1 Package

Total size: 55 M
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Upgrading   : atom-1.5.3-0.1.fc21.x86_64                                  1/2
  Cleanup     : atom-1.2.4-0.1.fc21.x86_64                                  2/2
  Verifying   : atom-1.5.3-0.1.fc21.x86_64                                  1/2
  Verifying   : atom-1.2.4-0.1.fc21.x86_64                                  2/2

Upgraded:
  atom.x86_64 1.5.3-0.1.fc21                                                    

Complete!

I find it gives better, more detailed, output than APT, pacman or ZYpp. Additionally it supports group installs, which can save one a lot of time installing several different pieces of software that belong to the one group. For example, to install the KDE desktop one would run root #  dnf install @kde-desktop. It also includes some actions (and yes these that are not included by basic or “simple” package managers like pacman). These include:

  • autoremove — remove no longer needed packages. For example, packages that were once required for a package to run but are no longer.
  • builddep — install the required build-dependencies of a package.
  • URL installs.

it also has support for use of wildcard operators. For example, root #  dnf install kernel</span>, will attempt (not necessarily succeeding though, in the case of package conflicts) all packages that’s name begins with the word “kernel”. This can be helpful and time-saving when one wishes to install all subpackages of a package (e.g., the -devel, -doc, *etc. subpackages).

Speed

Running root #  time dnf install -y vim-common returns:

Last metadata expiration check performed 0:17:31 ago on Sat Feb 13 22:08:01 2016.
Dependencies resolved.
================================================================================
 Package           Arch          Version                    Repository     Size
================================================================================
Reinstalling:
 vim-common        x86_64        2:7.4.827-1.fc23           fedora        6.0 M

Transaction Summary
================================================================================

Total download size: 6.0 M
Downloading Packages:
vim-common-7.4.827-1.fc23.x86_64.rpm            1.0 MB/s | 6.0 MB     00:05    
--------------------------------------------------------------------------------
Total                                           357 kB/s | 6.0 MB     00:17     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Reinstalling: vim-common-2:7.4.827-1.fc23.x86_64                          1/2
  Erasing     : vim-common-2:7.4.827-1.fc23.x86_64                          2/2
  Verifying   : vim-common-2:7.4.827-1.fc23.x86_64                          1/2
  Verifying   : vim-common-2:7.4.827-1.fc23.x86_64                          2/2

Reinstalled:
  vim-common.x86_64 2:7.4.827-1.fc23                                            

Complete!

real	0m33.853s
user	0m2.064s
sys	0m3.964s

as you can see, when I reinstalled vim-common the package was re-downloaded (even though I had just installed the package when I ran this command, so I thought, but was clearly mistaken, that it was in the DNF cache), which adds some time to the real time. To get a better estimate as to the actual installation time, let us take 17 seconds (the time recorded in this message as the total time taken to download the package) from the real time, getting 16.853s. This figure I think may be an inaccurate representation of its speed as DNF is supposed to be faster than yum.

Basic Usage

Table 2: Basic Usage of DNF
Action Command1 Description
Add a repository
root #  dnf config-manager --add-repo $URL
Add a DNF repository, the $URL must be to the repository's .repo file.
Build package from source N/A Building a package from source has to be done over several lines and involves using tools not provided by DNF.
Install build dependencies
root #  dnf builddep $package
Install the required build dependencies for $package.
Install package
root #  dnf install $package
Install the target package ($package) and all runtime dependencies.
Remove package
root #  dnf remove $package
Remove the target package ($package) and all runtime dependencies not required by other installed packages.
Search for keyword
root #  dnf search $package
Search package metadata (including name, description, URL, etc.) for provided regex.
Upgrade all packages
root #  dnf update
Upgrade all installed packages.
1: Note: in this table I use the short-hand notations $package and $URL to refer to the target package(s) or repository URL, respectively, that the user wishes to perform the mentioned action on.


Entropy

Entropy is the default package manager of Sabayon, although Sabayon also comes with the Portage package manager pre-installed, but only the use of Entropy is supported by the Sabayon community. Entropy has similarities to Portage, along with several key differences. It is written in Python and shell script, like Portage, but unlike Portage, which, by default, installs software from source code following instructions found in ebuilds, Entropy installs software from binary packages. These binary packages were originally built using Portage, however, then they are converted to binary packages suitable for Entropy using Entropy itself (via root #  equo pkg inflate $package.tbz2). Entropy has both an official command-line and graphical user interface; from the command-line it is called by the equo command, while Rigo is its GUI. Entropy is the second-youngest package manager mentioned in this post, after DNF, with its first public release being in 2007 and its first stable release being in 2012.

Entropy is not a front-end for any lower-level package managers, unlike APT which is a front-end for dpkg and DNF which is a front-end for RPM.

Beginner-Friendliness

It is a fairly beginner-friendly package manager, its command-line syntax is intuitive, for example, root #  equo install octave should install GNU Octave, without prompting, while root #  equo remove octave should uninstall it without prompting. The only prompting that Entropy does, unless you, the user, specify that it should by passing it the --ask or -a options to it, is asking if you accept any relevant package licenses that are not accepted by default. Its basic syntax is:

root #  equo [action] [option(s)] [target(s)]                                                              (2)

Several abbreviated actions exist, for example, i for install, rm for remove, up for update and u for upgrade. It has a graphical user interface which is always a nice beginner-friendly touch. Overall I would rate its beginner-friendliness at 8/10.

Customizability

As Entropy installs software from binary packages, there is no real freedom to customize the packages to your liking. Except by, of course, writing your own ebuild, or modifying existing ebuilds, to your liking and building and installing them. Or building/installing existing ebuilds in the Portage Tree or unofficial overlays with custom USE flags enabled. As far as customizing Entropy itself, there are several files in the /etc/entropy directory that can be used to customize Entropy’s options.

Development

Entropy package development is done in three major steps:

  • The creation or selection of a suitable ebuild.
  • The building of a Portage binary package from the ebuild by issuing the command root #  ebuild $package.ebuild package. Or, if the ebuild is in a presently-enabled Portage overlay, run root #  emerge -b $package. Where $package.ebuild is the name of the ebuild, including its file extensions, relative to the present working directory.
  • root #  equo pkg inflate $package.tbz2. Where $package.tbz2 is the binary package built by Portage, including its relative path to the present working directory. It is likely in the /usr/portage/packages directory.

If you wish to distribute your package (like in a repository), I am afraid you are left to your own devices. That is, the Open Build Service (OBS) does not store Entropy packages and there are no other free alternatives for hosting your package repositories that I am aware of, at least.

Features

Syntactically it is similar to both APT and Portage. See its options (e.g., -a/--ask for ask for confirmation before performing changes) are similar to Portage, but its actions are largely borrowed from APT. It cannot install packages from a URL, although it can install software from local packages. If you install a local package, that is also present (even if the version present there is different) in the Entropy repositories, then perform an upgrade odds are the package version in the Entropy repositories will be installed over it. I found its output more detailed and descriptive than APT, however, and similar in quality to that of DNF/yum. It does not support wildcards and its packages are usually not split up the way Debian and RPM packages often are. It, like Portage, can install meta-packages that serve no other purpose than to draw in several pieces of related software. For example, running root #  equo i gnome-base/gnome should install the core GNOME desktop components. It also has abbreviated commands (e.g., equo i is the equivalent to running equo install), which can come in handy.

Speed

Running root #  time equo i vim returned:

╠  @@ Calculating dependencies...
╠ ::  (100.0%) Sorting dependencies ::
╠  ## [R] [sabayonlinux.org] app-editors/vim-7.4.827|3   [7.4.827|3]
╠  @@ Packages needing to be installed/updated/downgraded: 1
╠  @@ Packages needing to be removed: 0
╠  @@ Download size: 0b
╠  @@ Freed disk space: 0.0b
╠  @@ You need at least: 2.5MB of free space
╠  ::: >>>  (1/1) 1 package
╠    ## Downloading: 1 package
╠    ## ( mirror #1 ) [app-editors:vim-7.4.827.291a631e2a270baad1f13a4392ceb7af9191b601~3.tbz2] @ http://debian.mirror.dkm.cz
╠   ## Aggregated download: 1 item
╠    # [1] debian.mirror.dkm.cz => app-editors:vim-7.4.827.291a631e2a270baad1f13a4392ceb7af9191b601~3.tbz2
╠    ## Checking package checksum...
╠    ## ( mirror #1 ) [app-editors:vim-7.4.827.291a631e2a270baad1f13a4392ceb7af9191b601~3.tbz2] success @ http://debian.mirror.dkm.cz
╠  +++ >>>  (1/1) app-editors/vim-7.4.827
╠    ## Unpacking: app-editors:vim-7.4.827.291a631e2a270baad1f13a4392ceb7af9191b601~3.tbz2
╠    ## Package phase: setup
╠    ## Installing package: app-editors/vim-7.4.827
╠    ## [Vim, an improved vi-style text editor]
╠    ## Updating installed packages repository: app-editors/vim-7.4.827
╠    ## Cleaning previously installed application data.
╠    ## Package phase: postremove
 * Updating documentation tags in /usr/share/vim/vim74
 * Calling eselect vi update...
╠    ## Package phase: postinstall
 * Updating documentation tags in /usr/share/vim/vim74
 * Calling eselect vi update...
╠    ## Cleaning: app-editors/vim-7.4.827
╠  @@ Installation complete.
╠  @@ Scanning configuration files to update
╠  @@ No configuration files to update.

real	0m7.621s
user	0m5.287s
sys	0m1.467s

So it took 7.621s total to reinstall this package. I personally think that this figure is not representative of its speed in practice, I think it is slower than all package managers except Portage and perhaps DNF and/or yum.

Basic Usage

Table 3: Basic Usage of Entropy
Action Command1 Description
Build package from source N/A Building a package from source has to be done over several lines and involves using tools not provided by Entropy.
Install build dependencies
root #  equo install -o $package
Install the required build dependencies for $package.
Install package
root #  equo install $package
Install the target package ($package) and all runtime dependencies.
Remove package
root #  equo remove $package
Remove the target package ($package) and all runtime dependencies not required by other installed packages.
Search for keyword
root #  equo search $package
Search package names and descriptions for provided regex.
Upgrade all packages
root #  equo update && equo upgrade
Upgrade all installed packages.
1: Note: in this table I use the short-hand notation $package to refer to the target package(s) that the user wishes to perform the mentioned action on.


pacman

pacman is the default package manager of Arch Linux and its various derivatives as well as at least two supposedly “independent” distributions, Frugalware Linux and KaOS. It adheres quite strictly to the Arch philosophy of keeping it simple, at least to those that understand it well enough. See, its syntax is far from intuitive or straight-forward to a beginner, in fact, it can quite easily become confusing, but once one understands pacman and how it works well enough, it becomes clearer. It is written almost entirely in C and this likely contributes to the fact that it is probably the fastest Linux package manager available today. pacman’s first stable release was in February 2002.2 It is not a front-end for any other lower-level package managers.

Its packages have the .pkg.tar.xz file extension and are generated by running the makepkg command (which is provided by the pacman package) in a directory in which a specialized Bash script called a PKGBUILD is located. The PKGBUILD, analogous to an RPM file’s specfile, contains instructions read by makepkg to build the package.

Arch Linux has two main types of repository: the pacman repositories which pacman accesses and uses to install software and the Arch User Repository (AUR). The AUR is managed by git and presently contains over 30,000 different PKGBUILDs for packages that are not in the pacman repositories and as pacman itself does not have access to this repository this leaves one with far fewer packages to choose from. Fortunately, however, several “AUR helpers” exist that have access to both the AUR and the pacman repositories. When it comes to installing packages in the AUR what many of these helpers will do is they will download the PKGBUILD (either by git cloning the AUR repository in which it lies or downloading a tarball snapshot of this repository), install any missing dependencies with either pacman or from the AUR, then build the package with makepkg and install it with pacman.

The most popular AUR helper, which is also the one I have the greatest experience with, is Yaourt, which is written in Bash script and has a pacman-like syntax. So running root #  yaourt -S atom-editor should build and install atom-editor from the AUR. Trizen is another AUR helper I have used, it has a pacman-like syntax, but unlike Yaourt it is written in Perl.

Beginner-Friendliness

As previously mentioned pacman has a syntax that is non-intuitive to newcomers, for example, to install a package one runs root #  pacman -S $package while to remove it one runs root #  pacman -Rs $package. If you are interested in making the transition from another package manager to pacman, I suggest you read the Pacman/Rosetta article at The ArchWiki, along with the pacman man page. pacman has no officially-supported graphical front-end, although unofficial front-ends (such as Octopi and Pamac) exist and are included, by default, in the Arch derivative, Manjaro Linux.

Its basic syntax is:

root #  pacman [options] [action] [target(s)]                                                             (3)

Customizability

pacman’s settings (like a list of enabled repositories) are stored in /etc/pacman.conf, but as pacman is a binary package manager some freedom is taken away from the user, in terms of customizing their system. Despite this, Arch Linux has the Arch Build System (ABS), a Portage Tree-like set of subdirectories found in /var/abs/ that contain the PKGBUILDs and associated other files used to build the software in the pacman repositories. The ABS is not included, by default, on Arch Linux, however, it has to be installed by the user and setup. Once installed, it is possible that the user can use it to customize all packages installed on their system to their liking and any extra packages they would like to install.

Development

Developing pacman packages is far simpler than developing any other packages mentioned in this post. See it involves just writing PKGBUILDs, which are easier to write, in my opinion, than ebuilds, rules files and spec files. Once one is written or desired adjustments are made to one, the user can test it by running user $  makepkg -s from within the PKGBUILD’s directory. This will download the upstream source code packages required, if they are not already in the PKGBUILD’s directory, install any required build dependencies for the package and build it, by following the instructions within the PKGBUILD.

Features

pacman’s feature set is fairly limited compared to other package managers mentioned in this post, with respect to previously mentioned features, at least. It does not have an autoremove (it is possible to do an autoremove though, by piping the output of one pacman command through another, namely by running root #  pacman -Qdtq | pacman -Rs) or builddep action (although the makepkg command can be passed the -s option to get it to install all required build dependencies, prior to making a package), nor does it support the use of wildcards. It also provides fewer details in its output than DNF or Entropy. It does support the use of meta-packages or package groups to automate the installation of a large group of related packages. For example, root #  pacman -S gnome should install all the basic components of the GNOME desktop. While root #  pacman -S gnome-extra installs assorted extra packages related to GNOME like its core application suite.

pacman does have several actions that can be built into a single pacman command, though, giving it more power and compactness in its syntax than more beginner-friendly package managers like APT or DNF. For example, root #  pacman -Syyu $package can be used to synchronize local repositories, upgrade all installed packages on the system (note this will not upgrade packages installed via the AUR or custom PKGBUILDs) and install the package(s) specified in $package. This is as opposed to root #  apt-get update && apt-get upgrade && apt-get install $package for APT and root #  dnf update && dnf install $package for DNF.

Speed

From root #  time pacman -S vim –noconfirm I received the output:

warning: vim-7.4.1294-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Packages (1) vim-7.4.1294-1

Total Installed Size:  2.70 MiB
Net Upgrade Size:      0.00 MiB

:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring                     [######################] 100%
(1/1) checking package integrity                   [######################] 100%
(1/1) loading package files                        [######################] 100%
(1/1) checking for file conflicts                  [######################] 100%
(1/1) checking available disk space                [######################] 100%
:: Processing package changes...
(1/1) reinstalling vim                             [######################] 100%

real	0m0.464s
user	0m0.227s
sys	0m0.067s

so it took 0.464s total to reinstall this package. I think this time is very fair, as in my experience pacman is the fastest Linux package manager I have ever used.

Basic Usage

Table 4: Basic Usage of pacman
Action Command1 Description
Build package from source
user $  makepkg
Build package from source, using instructions in the PKGBUILD in the present working directory (PWD).
Install build dependencies
user $  makepkg -s
Install the required build dependencies for package's whose PKGBUILD is in the PWD.
Install package
root #  pacman -S $package
Install the target package ($package) and all runtime dependencies.
Remove package
root #  pacman -Rs $package
Remove the target package ($package) and all runtime dependencies not required by other installed packages.
Search for keyword
root #  pacman -Ss $package
Search package names and descriptions for provided regex.
Upgrade all packages
root #  pacman -Syu
Upgrade all installed packages present in the pacman repositories.
1: Note: in this table I use the short-hand notation $package to refer to the target package(s) that the user wishes to perform the mentioned action on.


Portage

Portage is the default package manager of Gentoo Linux and many of its derivatives, including Calculate and Funtoo Linux. The main command that invokes Portage from the command-line, is emerge. It is written in Python and Bash script and unlike all other package managers mentioned in this post it works with source code packages, by default. As such there are several differences between it and other package managers, in term of how it operates.

Its chief repository is found in the /usr/portage directory (the so called “Portage Tree”, it can be searched from this website), which is structured similarly to the FreeBSD ports system and contains ebuilds, a specialized type of Bash script, along with patch files and Manifests (a file that contains checksums and file size information about ebuilds and other files). This structure is such that the top-level subdirectory of /usr/portage is for package categories like app-editors for text editors, x11-wm for window managers, etc., the next lower level is for specific packages (e.g., /usr/portage/app-editors/gvim is where gVim ebuilds and related files can be found). ebuilds contain instructions that Portage can use to build a binary software package (in the .tbz2 format) and/or install the software package from source code or a binary package from another distribution (e.g., Debian packages and RPM packages).

Additional Portage repositories (which are more commonly referred to as overlays), have the same internal file structure to the Portage Tree, that is, their top-level subdirectories are package categories and their subdirectories are for specific packages. They are managed by a tool also developed by the Gentoo Foundation called Layman which stores its repositories in the /var/lib/layman directory. For example, /var/lib/layman/sabayon-tools, if it exists on one’s system, would contain my Portage overlay, sabayon-tools. Layman is written in Python too and is not included with Gentoo Linux by default (although it is included with Sabayon Linux, by default) and instead has to be installed with Portage before it can be used.

Beginner-Friendliness

Portage is probably the least beginner-friendly package management system mentioned in this post, its syntax is less than intuitive and quite frequently installing, removing and upgrading software is not as simple as running a single command. This is due to USE flag constraints, package conflicts, etc., that the user sometimes has to deal with. It has no official graphical front-ends, although an unofficial GTK-based one called Porthole (app-portage/porthole) is available from the Portage Tree. Despite this it does have pretty high-quality documentation for a Linux package manager, so the really motivated and persistent beginners could probably learn how to use it without needing help from others. Overall I would rank it at 2-3/10 for beginner-friendliness.

Its basic syntax is:

root #  emerge [options] [action] [ebuild | tbz2file | file | @set | atom]                                 (4)

For further details on its syntax go here.

Customizability

Being a source code package manager, Portage affords users almost infinite control over the packages on their system. It does this via the specification of so called “USE flags”. They are usually options that ebuilds pass to the respective configure script of the package they build. The Portage Tree (PT) and unofficial Portage overlays usually contain several different versions of the same package too (each with different ebuilds), hence affording users a choice of multiple different versions of the same package. For example, the x11-wm/enlightenment package (which is for the Enlightenment window manager) at the time of writing has the following different versions available in the PT:

  • 0.16.9999
  • 0.17.9999
  • 0.18.8
  • 0.19.10
  • 0.19.12
  • 0.20.1
  • 0.20.2
  • 1.0.11
  • 1.0.17

These packages also differ in their allowed USE flags, the 0.20.2 package has the wayland USE flag, for example, which if enabled will build the package with Wayland support. Additionally one is free to set up one’s own overlay, like I have, and install one’s own custom packages using it.

Development

Package development with Portage is easier than developing Debian packages, about as difficult as developing RPM packages and more difficult than writing PKGBUILDs and developing pacman packages, in my opinion. By package development I mean both writing working ebuilds and building binary packages from them. Writing ebuilds is a skill that comes slowly and only by doing several examples, and having a good knowledge of Bash syntax is a prerequisite for doing it well. Those interested in writing ebuilds may wish to read the ebuild command man page and the ebuild file format man page, both of which are hosted on this site.

Features

Portage is one of the most feature-packed package managers out there. Its output can be made more detailed (or verbose) by passing the --verbose/-v flag to it. The --buildpkgonly/-B option can be passed to get it to only build a binary package and not install the program into the live file system. It does not do installs from a specified URL, although it can be used to install local binary packages, although they have to be in a specific location in the root file system. The way it downloads the source files, that are used to build the package, is via wget and, if possible, rsync.

Speed

Portage is, by far, the slowest package manager compared in this comparison, as it builds software packages from source code, by default. To test its speed I ran root #  time emerge app-editors/vim::sabayon-tools when the latest version of Vim (and the version in my sabayon-tools overlay) was 7.4.1342, the full output it gave was very long so I have placed it here and rather I will just give the time it took to reinstall app-editors/vim (none of the related packages like vim-core or gvim):

real	3m18.828s
user	2m6.109s
sys	0m20.541s

Basic Usage

Table 5: Basic Usage of Portage
Action Command1 Description
Build package from source
root #  emerge -B $package
Building packages from source code is as simple as passing the necessary flag to emerge.
Install build dependencies
root #  emerge -o $package
Install the required build dependencies for $package.
Install package
root #  emerge $package
Install the target package ($package) and all runtime dependencies.
Remove package
root #  emerge -C $package
Remove the target package ($package) and all runtime dependencies not required by other installed packages.
Search for keyword
root #  emerge --search $package
Search package names and descriptions for provided regex.
Upgrade all packages
root #  emerge --sync
root #  layman -S
root #  emerge -uDU --with-bdeps=y @world
Upgrade all installed packages, after synchronizing (with their respective version control system) the Portage Tree and all locally-installed overlays.
1: Note: in this table I use the short-hand notation $package to refer to the target package(s) that the user wishes to perform the mentioned action on.


yum

Yellowdog Updater, Modified (yum) is a front-end for the RPM package manager that is written in Python. Prior to the release of Fedora 22 in May 2015 it was the default package manager of Fedora, and it is still the default package manager of CentOS, Oracle Linux, Red Hat Enterprise Linux (RHEL) and Scientific Linux. yum, as its name suggests, started off as a modified version of the Yellowdog Updater (YUP) used by the Yellow Dog Linux distribution, that was developed for use by the Red Hat Linux systems at Duke University in the early 2000s. RHL at the time used the up2date package manager. Later yum was adopted by CentOS, Fedora and their descendants, along with Yellow Dog Linux itself. Its development has since been ceased in favour of its supposedly faster successor, DNF.

Beginner-Friendliness

Like DNF yum’s syntax is fairly intuitive with root #  yum install $package to install a package and root #  yum remove $package to uninstall it. It also has the Qt-based Apper and GTK+ based GNOME Software graphical front-ends available. I would personally rate it at 7-8/10 for beginner-friendliness.

Its basic syntax is:

root #  yum [action] [option(s)] [target(s)]                                                               (5)

Customizability

As yum is a binary package manager its packages cannot be as easily customized as source code packages would be. Source code packages can be downloaded though (with the command user $  yumdownloader –source $package), modified, rebuilt and installed as described in the DNF section of this post.

Development

Developing packages for yum is the same as developing DNF packages as they are both RPM packages. You can use the method outlined at the Fedora Wiki or using the Open Build Service.

Features

Like its descendant, DNF, yum has in-built support for downloading and then installing software packages from a specified URL, via running:

root #  yum install $URL

all features mentioned for DNF also exist for yum, including group installs.

Speed

The output of root #  time yum reinstall -y vim-common was:

Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
 * base: mirror.overthewire.com.au
 * extras: mirror.overthewire.com.au
 * updates: mirror.overthewire.com.au
Resolving Dependencies
--> Running transaction check
---> Package vim-common.x86_64 2:7.4.160-1.el7 will be reinstalled
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package            Arch           Version                   Repository    Size
================================================================================
Reinstalling:
 vim-common         x86_64         2:7.4.160-1.el7           base         5.9 M

Transaction Summary
================================================================================
Reinstall  1 Package

Total download size: 5.9 M
Installed size: 21 M
Downloading packages:
vim-common-7.4.160-1.el7.x86_64.rpm                        | 5.9 MB   00:06     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : 2:vim-common-7.4.160-1.el7.x86_64                            1/1
  Verifying  : 2:vim-common-7.4.160-1.el7.x86_64                            1/1

Installed:
  vim-common.x86_64 2:7.4.160-1.el7                                             

Complete!

real    0m14.461s
user    0m3.574s
sys     0m1.619s

discounting the time taken to perform the download (6 seconds) this give a real time to reinstall vim-common of 8.461s. Must admit this seems wrong as it is less time than DNF took to install the same package. I think the time measured is unfair and not really representative of its speed, I believe it is slower than all package managers I have used except Entropy and Portage.

Basic Usage

Table 6: Basic Usage of yum
Action Command1 Description
Add a repository
root #  yum config-manager --add-repo $URL
Add a yum repository, the $URL must be to the repository's .repo file.
Build package from source N/A Building a package from source has to be done over several lines and involves using tools not provided by yum.
Install build dependencies
root #  yum-builddep $package
Install the required build dependencies for $package.
Install package
root #  yum install $package
Install the target package ($package) and all runtime dependencies.
Remove package
root #  yum remove $package
Remove the target package ($package) and all runtime dependencies not required by other installed packages.
Search for keyword
root #  yum search $package
Search package metadata (including name, description, URL, etc.) for provided regex.
Upgrade all packages
root #  yum update
Upgrade all installed packages.
1: Note: in this table I use the short-hand notations $package and $URL to refer to the target package(s) or repository URL, respectively, that the user wishes to perform the mentioned action on.


ZYpp

ZYpp (also known as libzypp) is the default package manager of openSUSE, SUSE Linux Enterprise (SLE) and their derivatives. ZYpp provides the libraries for openSUSE’s command-line package manager, zypper and its graphical package manager, YaST2. ZYpp serves as a front-end for the RPM package manager, providing advanced features like repository management, dependency resolution, etc., making it similar to DNF and yum in that regard. ZYpp, unlike most other RPM package manager front-ends I am aware of (the only exception is, of course, APT-RPM), is written predominantly in the compiled language, C++, as opposed to DNF and yum which are written mostly in the interpreted language, Python, and urpmi (from Mageia/Mandriva/OpenMandriva) which is written in the interpreted language, Perl. The significance of this, from the point of view of users, is that it may give ZYpp a speed advantage over these package managers. Zypper is written in C++ too while YaST is written in Ruby (another interpreted language, equally, if not more, slow than Perl or Python).

Beginner-Friendliness

The YaST2 Control Center

The YaST2 Control Center

ZYpp is a fairly beginner-friendly package manager. Zypper has an intuitive syntax, which includes abbreviated commands such as zypper in for zypper install, zypper rm for zypper remove and zypper up for zypper update. YaST2 is probably the most powerful graphical package management system I have ever used, in that it gives users the greatest number of options, with which to configure their system. YaST2 is also the default installer of openSUSE, that is, it is used to install the openSUSE operating system. Overall I would rate it as 9/10 for beginner-friendliness.

Its basic syntax is:

root #  zypper [action] [option(s)] [target(s)]                                                            (6)

Customizability

ZYpp, being a binary package manager, does not afford users much control over installed packages, although, it is possible to download the source packages (that is, the packages with the file extension .src.rpm) of installed packages, customize them and install the customized package.

Development

As ZYpp works with RPM packages, following the Fedora Wiki instructions should suffice. It essentially involves creating a mock user called makerpm, with the required file system structure, getting the required spec file, source code files, etc. into their respective locations in your /home/makerpm/rpmbuild directory and finally running user $  rpmbuild -ba $specfile.spec (from the rpmdevtools package, which is not in the default repositories of any presently-supported openSUSE version, so to add it I recommend you use the devel:tools repository. Here is where you can find one-click install files and installation instructions for the rpmdevtools package from this repository).

Here is an example /home/makerpm/rpmbuild directory structure, to serve as a guide for the discussion that follows:

.
├── BUILD
│   ├── atom-1.5.3.tar.gz
│   └── atom-1.6.0-beta3
├── BUILDROOT
│   ├── atom-0.194.0-1.x86_64
│   ├── atom-1.4.3-1.x86_64
│   ├── atom-1.5.2-0.x86_64
│   └── atom-beta-1.6.0-3.x86_64
├── OTHER
│   ├── atom.cpio.rsasign
│   ├── pesign-repackage.spec
│   ├── vim-7.4-rpmlintrc
│   └── vim.cpio.rsasign
├── RPMS
│   ├── noarch
│   └── x86_64
├── SOURCES
│   ├── apparmor.vim
│   ├── atom-beta.desktop
│   ├── atom.desktop
│   ├── gvim.desktop
│   ├── gvim.png
│   ├── gvim.svg
│   ├── missing-vim-client
│   ├── README.Japanese-XIM
│   ├── spec.skeleton
│   ├── suse.gvimrc
│   ├── suse.vimrc
│   ├── v1.5.3.tar.gz
│   ├── v1.6.0-beta3.tar.gz
│   ├── v7.4.1344.tar.gz
│   ├── vim132
│   ├── vim-7.1.314-CVE-2009-0316-debian.patch
│   ├── vim-7.3-filetype_changes.patch
│   ├── vim-7.3-filetype_ftl.patch
│   ├── vim-7.3-filetype_spec.patch
│   ├── vim-7.3-gvimrc_fontset.patch
│   ├── vim-7.3-help_tags.patch
│   ├── vim-7.3-mktemp_tutor.patch
│   ├── vim-7.3-name_vimrc.patch
│   ├── vim73-no-static-libpython.patch
│   ├── vim-7.3-sh_is_bash.patch
│   ├── vim-7.3-use_awk.patch
│   ├── vim-7.4-disable_lang_no.patch
│   ├── vim-7.4-filetype_apparmor.patch
│   ├── vim-7.4-filetype_mine.patch
│   ├── vim-7.4-highlight_fstab.patch
│   ├── vim-7.4-rpmlintrc
│   ├── vim.changes
│   ├── vimrc_example1
│   ├── vimrc_example2
│   ├── vitmp.1
│   └── vitmp.c
├── SPECS
│   ├── atom-beta.spec
│   ├── atom.spec
│   ├── build-rpm
│   └── vim.spec
├── SRPMS
│   ├── atom-1.5.3-0.src.rpm
│   └── vim-7.4.1344-0.src.rpm

The contents of the BUILD, BUILDROOT, RPMS, SRPMS and OTHER folders are generated automatically when rpmbuild is run, so you need not worry yourself about their content. It is the content of the SOURCES and SPECS directories that package developers have to concern themselves with. SOURCES contains the package’s upstream source, along with any patches or other files that are specified as sources in the package’s spec file. SPECS contains the most important file of all to RPM development, the one that package developers likely spend the greatest amount of time writing and fixing, the spec file (which has the .spec file extension). The build-rpm subdirectory in this directory can be ignored as it too is built automatically when rpmbuild is run. One thing about the rpmbuild command that I really dislike is that it cannot download the upstream source code file for you, and place it in the SOURCES directory if it is not already there. pacman’s makepkg command and Portage’s ebuild command do this automatically for users.

Alternatively, for most packages you can use the Open Build Service, which can also be run locally without ever submitting the package to one’s OBS repository. Some packages cannot be built using the OBS though, which is something I found out when I was trying to build my first RPM package, ironically, which was the Atom text editor.3 It was an exception as the OBS does not give packages Internet access during compilation. The Atom text editor is built or compiled by running the script/build command in its source’s top-level directory, which requires Internet access as it downloads several Node.js modules and Electron using git and compiles them. A solution I came up with that ended up crashing and burning (refer to the forum thread mentioned in 3) was to compress a source code directory in which script/build had been run already (and as this command compiles everything in the source directory, this should have meant that I would not have to run script/build again in my atom spec file) and use that as the spec file’s source.

Features

ZYpp is very feature-packed, it possesses all the features previously mentioned of DNF, with one exception: group installs. Instead if you wish to install a group of packages you have to use patterns, similarly to APT’s tasks. For example, to install all members of the pattern books one would run: root #  zypper in -t pattern books. To list all available patterns run root #  zypper pt. YaST2 can also do so called “one-click installs”, wherein you click a button on a webpage, that is hyperlinked to a file with the .ymp file extension, which if your web browser preferences are set properly, should automatically download. If you click on the file either in your browser or in your file manager, it will open YaST2 which will, with your permission, attempt to install the package (or even group of packages specified by some pattern) specified in the .ymp file. This system can be handy (and a time-saver) when one wishes to install a package from a repository not presently added, although if I already have the repository in question added, I usually prefer to use zypper to install the package.

Speed

On openSUSE Tumbleweed running root #  time zypper –no-refresh in -y –force vim returned:

Loading repository data...
Reading installed packages...
Forcing installation of 'vim-8.0.130-1.1.x86_64' from repository 'Main Repository (OSS)'.
Resolving package dependencies...

The following package is going to be reinstalled:
  vim

1 package to reinstall.
Overall download size: 0 B. Already cached: 1.4 MiB. No additional space will be used or
freed after the operation.
Continue? [y/n/? shows all options] (y): y
In cache vim-8.0.130-1.1.x86_64.rpm                (1/1),   1.4 MiB (  2.9 MiB unpacked)
Checking for file conflicts: .....................................................[done]
(1/1) Installing: vim-8.0.130-1.1.x86_64 .........................................[done]
zypper --no-refresh install -y --force vim  1.02s user 0.22s system 14% cpu 8.338 total

giving time of 1.02s. Making it the second-fastest package manager in this comparison.

Basic Usage

Table 7: Basic Usage of zypper
Action Command1 Description
Add a repository
root #  zypper ar -f $URL
Add a zypper repository, the $URL must be to the repository's .repo file.
Install build dependencies
root #  zypper source-install -d $package
Install the required build dependencies for $package.
Install package
root #  zypper install $package
Install the target package ($package) and all runtime dependencies.
Install package from source
root #  zypper source-install $package
Install package from .src.rpm.
Remove package
root #  zypper remove $package
Remove the target package ($package) and all runtime dependencies not required by other installed packages.
Search for keyword
root #  zypper search $package
Search package metadata (including name, description, URL, etc.) for provided regex.
Upgrade all packages
root #  zypper update
Upgrade all installed packages.
1: Note: in this table I use the short-hand notations $package and $URL to refer to the target package(s) or repository URL, respectively, that the user wishes to perform the mentioned action on.


Summary

Table 8: A Summary of Package Managers
Package Manager BF BS CMB DIP EOD GUI OCI PFE SC TR WC
APT 5-7 No 1-4 No 1-4 Yes Yes .deb, .rpm (APT-RPM) No 2.783s Yes
DNF 8 No 5 Yes 5-6 Yes No .rpm, .src.rpm No 16.853s Yes
Entropy 8 No 7 Yes 5-7 Yes No .tbz2 Yes 7.621s No
pacman 6 Yes 8-9 No 9 No No .pkg.tar.xz, PKGBUILD No 0.464s No
Portage 2-3 Yes 9 No 7-8 No No .ebuild, .tbz2 Yes 198.83s No
yum 7-8 No 5 Yes 5-6 Yes No .rpm, .src.rpm No 8.461s Yes
ZYpp 9 Yes 6 Yes 5-6 Yes Yes .rpm, .src.rpm Yes 1.02s Yes

The headers of each section are abbreviated to save space. Scroll your mouse pointer over them to show what they mean in full. The <abbr> tag is used in the markup of this web page to show this extra information, which according to w3schools should work in the following web browsers:

  • Chromium / Google Chrome
  • Edge / Internet Explorer
  • Mozilla Firefox
  • Opera
  • Safari


Footnotes

  1. RPM was originally abbreviated from Red Hat Package Manager, but now it is a recursive acronym for RPM Package Manager. 

  2. pacman Home Page (2 March 2015). Retrieved 15 February 2016. 

  3. If you wish to offer me a solution to this issue, that does not involve me creating new OBS packages for all of Atom’s many node module dependencies and Electron, feel free to leave me a reply here at the thread in which I asked how to build Atom using the OBS at the openSUSE Forums  2

Comments