Difference between revisions of "Pacman"
|Line 54:||Line 54:|
== Introduction ==
== Introduction ==
Packages in arch repositories are constantly upgraded. When a package is upgraded, its old version is removed from the repository. There are no major arch releases. Each package is upgraded as new versions become available from upstream sources. The repository is always coherent. (The packages in the repository always have compatible versions.) This type of repository is called a '''rolling archive'''. Before packages are upgraded in the '''core''', '''extra''' and '''community''' repositories, they are tested in the '''testing
Packages in arch repositories are constantly upgraded. When a package is upgraded, its old version is removed from the repository. There are no major arch releases. Each package is upgraded as new versions become available from upstream sources. The repository is always coherent. (The packages in the repository always have compatible versions.) This type of repository is called a '''rolling archive'''. Before packages are upgraded in the '''core''', '''extra''' and '''community''' repositories, they are tested in the '''testing''' , to ensure that the distribution is stable.
Revision as of 15:20, 3 February 2013
ro:Pacman zh-CN:Pacman zh-TW:Pacman Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary heading Template:Article summary link Template:Article summary link Template:Article summary link Template:Article summary link Template:Article summary end
The pacman package manager is one of the major distinguishing features of Arch Linux. It combines a simple binary package format with an easy-to-use build system. The goal of pacman is to make it possible to easily manage packages, whether they are from the official Arch repositories or the user's own builds.
Pacman keeps the system up to date by synchronizing package lists with the master server. This server/client model also allows user to download/install packages with a simple command, complete with all required dependencies.
Pacman is written in the C programming language and uses the
.pkg.tar.xz package format.
pacman -Ql pacman | grep bin
- 1 Introduction
- 2 Configuration
- 3 Usage
- 4 Troubleshooting
- 5 See also
Packages in arch repositories are constantly upgraded. When a package is upgraded, its old version is removed from the repository. There are no major arch releases. Each package is upgraded as new versions become available from upstream sources. The repository is always coherent. (The packages in the repository always have compatible versions.) This type of repository is called a rolling archive. Before packages are upgraded in the core, extra and community repositories, they are tested in the testing repository, to ensure that the distribution is stable.
pacman saves to disk a list of packages available in the repository. This list is not automatically updated (refreshed). You can refresh the list using
pacman -Syy refreshes the list even if it appears to be up to date. (
pacman -Syy is a good idea when you change the repository mirror used by pacman. Mirrors can be out of sync and the package list from the old mirror may not correspond to the package list of the new mirror, even though the dates of the lists may suggest that they do.)
pacman -S mypackage installs mypackage and all its dependencies. If mypackage has been upgraded since the last refresh of the package list, then the required version of mypackage will not be found in the repository and
pacman -S mypackge fails with a message. mypackage's dependencies are listed in the Depends On entry of mypackage's metainformation. (mypackage's metainformation can be listed with
pacman -Si mypackage for packages in the package list and with
pacman -Qi mypackage for installed packages). If mypackage or its dependencies are already installed, they are upgraded to the version in the package list. If
pacman -S mypackage finds any conflicts (installed packages which are listed in the Conflicts With entry of the mypackage's metainformation) then it fails with a message. However,
pacman -S mypackage does not check for broken dependencies which may appear from the possible upgrade of mypackage or one of its dependencies. It is possible that an already installed package which depends on an upgraded package is unable to function with the new version of the upgraded package. This may break your system.
The solution is to never run
pacman -Sy, which could be followed by
pacman -S mypackage, but to always run
pacman -Syu, which upgrades all packages after the refresh of the available package list. This ensures that when you run
pacman -S mypackage all packages installed on the system have compatible versions.
When you run
pacman -Syu there is a small chance that you will have to perform corrections on your system in order to have it running as you like. Important corrections are advertised here: https://wiki.archlinux.org/index.php/Wiki_News. They are very rare (three in 2012). However, you may like to run
pacman -Syu only when you have time to perform corrections and not when you rely on your system. It is a good idea to run
pacman -Syu often in order to minimize the difficulty of adjustment, whenever it arises.
pacman -R mypackage removes mypackage. If other packages depend on mypackage, then it fails with a message. In order to remove them too, run
pacman -Rc mypackage. Of course, you should carefully check the list of packages to be removed before you remove them.
pacman -R mypackage does not remove mypackage's dependencies which have been installed as dependencies (not explicitly, Install Reason in mypackage's metainformation) and are not required by other packages. In order to do that, you run
pacman -Rs mypackage. The complete command would be
pacman -Rcs mypackage.
pacman always lists packages to be installed or removed and asks for permission before it takes action. To inhibit any action, use
As you can see, pacman operates at a lower level compared to yum and apt. This requires more attention from you in using it, but it also empowers you with better control over your system.
For those who have used other linux distributions before, there is a helpful Pacman Rosetta.
Pacman's settings are located in
/etc/pacman.conf. This is the place where the user configures the program to work in the desired manner. In-depth information about the configuration file can be found in man pacman.conf.
General options are in the
[options] section. Read the man page or look in the default
pacman.conf for information on what can be done here.
Skip package from being upgraded
To skip upgrading a specific package, specify it as such:
For multiple packages use a space-separated list, or use additional
Skip package group from being upgraded
As with packages, skipping a whole package group is also possible:
Skip files from being installed to system
To always skip installation of specific directories list them under
NoExtract. For example, to avoid installation of systemd units use this:
This section defines which repositories to use, as referred to in
/etc/pacman.conf. They can be stated here directly or included from another file (such as
/etc/pacman.d/mirrorlist), thus making it necessary to maintain only one list.
#[testing] #SigLevel = PackageRequired #Include = /etc/pacman.d/mirrorlist [core] SigLevel = PackageRequired Include = /etc/pacman.d/mirrorlist [extra] SigLevel = PackageRequired Include = /etc/pacman.d/mirrorlist #[community-testing] #SigLevel = PackageRequired #Include = /etc/pacman.d/mirrorlist [community] SigLevel = PackageRequired Include = /etc/pacman.d/mirrorlist # Users If you want to run 32 bit applications on your x86_64 system, # enable the multilib repositories as required here. #[multilib-testing] #SigLevel = PackageRequired #Include = /etc/pacman.d/mirrorlist #[multilib] #SigLevel = PackageRequired #Include = /etc/pacman.d/mirrorlist # An example of a custom package repository. See the pacman manpage for # tips on creating your own repositories. #[custom] #SigLevel = Optional TrustAll #Server = file:///home/custompkgs
Pacman 4 supports signed packages, which adds an extra layer of security to the packages. To enable signature verification, take a look here.
What follows is just a small sample of the operations that pacman can perform. To read more examples, refer to man pacman.
Installing specific packages
To install a single package or list of packages (including dependencies), issue the following command:
# pacman -S package_name1 package_name2 ...
Sometimes there are multiple versions of a package in different repositories, e.g. [extra] and [testing]. To install the former version, the repository needs to be defined in front:
# pacman -S extra/package_name
Installing package groups
Some packages belong to a group of packages that can all be installed simultaneously. For example, issuing the command:
# pacman -S gnome
will install all the packages that belong to the
gnome group. To see what packages belong to the gnome group, run:
# pacman -Sg gnome
Also visit https://www.archlinux.org/groups/ to see what package groups are available.
pacman -Sy package_name); this can lead to dependency issues. See #Partial upgrades are unsupported and https://bbs.archlinux.org/viewtopic.php?id=89328.
To remove a single package, leaving all of its dependencies installed:
# pacman -R package_name
To remove a package and its dependencies which are not required by any other installed package:
# pacman -Rs package_name
To remove a package, its dependencies and all the packages that depend on the target package:
# pacman -Rsc package_name
To remove a package, which is required by another package, without removing the dependent package:
# pacman -Rdd package_name
Pacman saves important configuration files when removing certain applications and names them with the extension:
.pacsave. To prevent the creation of these backup files use the
# pacman -Rn package_name
Pacman can update all packages on the system with just one command. This could take quite a while depending on how up-to-date the system is. This command can synchronize the repository databases and update the system's packages (excluding 'local' packages that are not in the configured repositories):
# pacman -Syu
Pacman is a powerful package management tool, but it does not attempt to handle all corner cases. Read The Arch Way if this causes confusion. Users must be vigilant and take responsibility for maintaining their own system. When performing a system update, it is essential that users read all information output by pacman and use common sense. If a user-modified configuration file needs to be upgraded for a new version of a package, a
.pacnew file will be created to avoid overwriting settings modified by the user. Pacman will prompt the user to merge them. These files require manual intervention from the user and it is good practice to handle them right after every package upgrade or removal. See Pacnew and Pacsave Files for more info.
Before upgrading, it is advisable to visit the Arch Linux home page to check the latest news (or subscribe to the RSS feed): when updates require out-of-the-ordinary user intervention (more than what can be handled simply by following the instructions given by pacman), an appropriate news post will be made.
If one encounters problems that cannot be solved by these instructions, make sure to search the forum. It is likely that others have encountered the same problem and have posted instructions for solving it.
Querying package databases
Pacman queries the local package database with the
-Q flag; see:
$ pacman -Q --help
and queries the sync databases with the
-S flag; see:
$ pacman -S --help
Pacman can search for packages in the database, searching both in packages' names and descriptions:
$ pacman -Ss string1 string2 ...
To search for already installed packages:
$ pacman -Qs string1 string2 ...
To display extensive information about a given package:
$ pacman -Si package_name
For locally installed packages:
$ pacman -Qi package_name
-i flags will also display the list of backup files and their modification states:
$ pacman -Qii package_name
To retrieve a list of the files installed by a package:
$ pacman -Ql package_name
For packages not installed, use pkgfile.
One can also query the database to know which package a file in the file system belongs to:
$ pacman -Qo /path/to/file_name
To list all packages no longer required as dependencies (orphans):
$ pacman -Qdt
To list a dependency tree of a package:
$ pactree package_name
To list all the packages depending on a package, use
whoneeds from pkgtools:
$ whoneeds package_name
Upgrade the system and install a list of packages (one-liner):
# pacman -Syu package_name1 package_name2 ...
Download a package without installing it:
# pacman -Sw package_name
Install a 'local' package that is not from a remote repository (e.g. the package is from the AUR):
# pacman -U /path/to/package/package_name-version.pkg.tar.xz
Install a 'remote' package (not from a repository stated in pacman's configuration files):
# pacman -U http://www.example.com/repo/example.pkg.tar.xz
Clean the package cache of packages that are not currently installed (
# pacman -Sc
Clean the entire package cache:
# pacman -Scc
-Sccswitches, consider using
paccachefrom . This offers more control over what and how many packages are deleted. Run
paccache -hfor instructions.
Partial upgrades are unsupported
Arch Linux is a rolling release, and new library versions will be pushed to the repositories. The developers and Trusted Users will rebuild all the packages in the repositories that need to be rebuilt against the libraries. If the system has locally installed packages (such as AUR packages), users will need to rebuild them when their dependencies receive a soname bump.
This means that partial upgrades are not supported. Do not use
pacman -Sy package or any equivalent such as
pacman -Sy and then
pacman -S package. Always upgrade before installing a package -- particularly if pacman has refreshed the sync repositories. Be very careful when using
IgnoreGroup for the same reason.
If a partial upgrade scenario has been created, and binaries are broken because they cannot find the libraries they are linked against, do not "fix" the problem simply by symlinking. Libraries receive soname bumps when they are not backwards compatible. A simple
pacman -Syu to a properly synced mirror will fix the issue as long as pacman is not broken.