Upgrading the system
It is recommended to perform full system upgrades regularly via Pacman#Upgrading packages, to enjoy both the latest bug fixes and security updates, and also to avoid having to deal with too many package upgrades that require manual intervention at once. When requesting support from the community, it will usually be assumed that the system is up to date.
Make sure to have the Arch install media or another Linux “live” CD/USB available so you can easily rescue your system if there is a problem after updating. If you are running Arch in a production environment, or cannot afford downtime for any reason, test changes to configuration files, as well as updates to software packages, on a non-critical duplicate system first. Then, if no problems arise, roll out the changes to the production system.
If the system has packages from the AUR, carefully upgrade all of them.
pacman is a powerful package management tool, but it does not attempt to handle all corner cases. Users must be vigilant and take responsibility for maintaining their own system.
Read before upgrading the system
Before upgrading, users are expected to visit the Arch Linux home page to check the latest news, or alternatively subscribe to the RSS feed or the arch-announce mailing list. 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.
Before upgrading fundamental software (such as the kernel, xorg, systemd, or glibc) to a new version, look over the appropriate forum to see if there have been any reported problems.
Users must equally be aware that upgrading packages can raise unexpected problems that could need immediate intervention; therefore, it is discouraged to upgrade a stable system shortly before it is required for carrying out an important task. Instead, wait to upgrade until there is enough time available to resolve any post-upgrade issues.
Tip: You could use a pacman hook like informantAUR which prevents you from updating if there is fresh Arch News that you have not read since the last update ran.
Avoid certain pacman commands
Avoid doing partial upgrades. In other words, never run
pacman -Sy; instead, always use
Generally avoid using the
--overwrite option with pacman. The
--overwrite option takes an argument containing a glob. When used, pacman will bypass file conflict checks for files that match the glob. In a properly maintained system, it should only be used when explicitly recommended by the Arch Developers. See the #Read before upgrading the system section.
Avoid using the
-d option with pacman.
pacman -Rdd package skips dependency checks during package removal. As a result, a package providing a critical dependency could be removed, resulting in a broken system.
Partial upgrades are unsupported
Arch Linux is a rolling release distribution. That means when new library versions are pushed to the repositories, the Developers and Package Maintainers rebuild all the packages in the repositories that need to be rebuilt against the libraries. For example, if two packages depend on the same library, upgrading only one package might also upgrade the library (as a dependency), which might then break the other package which depends on an older version of the library.
That is why partial upgrades are not supported. Do not use:
pacman -Sy package
pacman -Sy followed by
pacman -S package (Note the absence of
-Su in the installation of the package.)
pacman -Syuw (Note that
pacman -Syuw does imply the same risks like
pacman -Sy, as it will update the pacman sync database without installing the newer packages.)
When refreshing the package database, always do a full upgrade with
pacman -Syu. Note that if
pacman -Syu does not perform the upgrade because of an error, the end result is the same as running
pacman -Sy. Therefore, the error must be resolved and the upgrade operation completed as soon as possible.
Be very careful when using
IgnoreGroup for the same reason. If the system has locally built packages (such as AUR packages), users will need to rebuild them when their dependencies receive a soname bump.
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 problem as long as pacman is not broken.
The bash script checkupdates, included with the pacman-contrib package, provides a safe way to check for upgrades to installed packages without running a system update at the same time, and provides an option to download the pending updates to the pacman cache without touching the sync database.
Act on alerts during an upgrade
When upgrading the system, be sure to pay attention to the alert notices provided by pacman. If any additional actions are required by the user, be sure to take care of them right away. If a pacman alert is confusing, search the forums and the recent news posts for more detailed instructions.
Deal promptly with new configuration files
When pacman is invoked, .pacnew and .pacsave files can be created. Pacman provides notice when this happens and users must deal with these files promptly. Users are referred to the pacman/Pacnew and Pacsave wiki page for detailed instructions.
Also, think about other configuration files you may have copied or created. If a package had an example configuration that you copied to your home directory, check to see if a new one has been created.