So far I have only really described package management in terms of installing new packages. There is a lot more to it, and since Pacman is such an intrinsic component of ArchLinux, I thought I ought to discuss package management a little more deeply.
Like most package management systems, there exist some package repositories that are hosted somewhere on the net. Arch Linux has current, extra, testing and unstable. According to the documentation, by default, Pacman only knows about current which provides your basic system components. If you want a graphical desktop and multimedia functionality, etc., you'll need to configure Pacman to use extra too. I must confess, I don't recall having to change anything in /etc/pacman.conf to achieve this. Of course, if I did then it was only a matter of uncommenting one line, which is maybe why my memory is failing me. Alternatively, maybe the Pacman developers have stopped being so conservative and are now providing extra by default too, but the documentation team haven't kept up! Testing and unstable are pretty obvious in their purpose, and I must admit that I'm not that interested in experimenting with their contents just yet! The first job you must do is get in sync with your chosen repositories should you choose to download from them, which is done with pacman -Sy.
Before you can commence installing, you have to know the package names as they are stored in the repositories, otherwise Pacman won't know what you're asking for. The basic approach is using the -Ss <string> argument which will return any packages that contain the string in their names or descriptions, e.g.,
$ pacman -Ss p2p extra/amule 2.0.0rc8-1 aMule is a eMule-like client for ed2k p2p network extra/gift 0.11.8.1-1 A bridge between P2P protocols and front-ends. extra/napshare 1.3-1 A complete, fully featured Gnutella P2P client extra/xmule 1.9.5-1 An easy to use, multi-platform clone of the eMule P2P filesharing client
Within a repository, packages are often divided into categories, such as daemons, editors, games, etc. ArchLinux packages follow such a scheme, but I have yet to find a way, via pacman to get access to this information. So, for example, you want to search to see all the possible editors available in the current repository. This type of query is only available via the ArchLinux package search web page. Still, maybe it's not the sort of feature Pacman developers thought you need since you are supposed to be a competent user, and therefore know the names of the packages you want to install, rather than just browse. Maybe my browsing habits stem from my Gentoo days which had a fairly fine-grain package tree stored locally in /usr/portage. I used to look through and when I'd see something that looked interesting that I never heard of before, I would emerge it and play with it for a while.
Anyway, once who know what you want, you have seen how easy it is to install, and all dependencies will be satisfied. It's worth noting that systems such as apt-get with Debian have a reputation for being a little over-zealous and installing masses of packages, some of which seem to have no relevance. ArchLinux has been praised for being more streamlined in this respect, however, is equally at risk. This is because this issue is not the really down to the dependency checking algorithms, it is due to the package maintainer going overboard on specifying more dependencies than are actually needed. ArchLinux package maintainers do have a nice system for specifying runtime dependencies and compilation dependencies to help ensure that only the necessary packages are installed.
Removing packages is also a doddle. You get a variety of options. pacman -R foo will remove the package foo, but leave any configuration files associated with it. pacman -Rn foo will remove package and config files. Of course, the package that you wish to remove may have installed dependencies that are no longer required by any other package. The command pacman -Rs foo removes recursively, and will remove any dependencies if they are not required. There is another option, the “cascade” option, which as far as I can gather will remove target package, plus dependencies, regardless of whether they are required by other packages! Of course, I could be wrong – but I've not had the guts to try it in fear it'll mess something up!
It's worth noting that by default, if and when a new version of the Linux kernel is released and uploaded to the current repository, the next time you run the update command (pacman -Syu), this version will be installed and overwrite your current kernel. Now, in theory, I like this idea. I personally like to keep up-to-date with the Linux kernel, so how handy is it that Pacman just upgrades you with very little effort. However, in practise, you can see it really opens itself up for problems. I seem to recall how kernel 2.6.8 seemed to break CD burning for non-root users. You can prevent prevent any package being upgraded if you explicitly add it to your /etc/pacman.conf file (in this instance: IgnorePkg=kernel26), although I personally think this should be the default, and for users who know what they are doing, can comment out that line if they are happy with the consequences. Additionally, perhaps the ArchLinux developers who maintain the kernel package could write a script that backs up the old kernel so that it would be easier to recover should a serious problem occur with the upgraded kernel.
The other aspect of package management is the Arch Build System. It is this system that allows users to build new packages that can be installed with Pacman. It is also possible to recompile existing packages to amend the configure arguments, or to use alternative compiler flags. This is a substantial topic on its own and so I won't cover it any further – I simply wanted to highlight that these features do exist.