Arch linux update command

System maintenance

Regular system maintenance is necessary for the proper function of Arch over a period of time. Timely maintenance is a practice many users get accustomed to.

Contents

Check for errors

Failed systemd services

Check if any systemd services have failed:

See systemd#Using units for more information.

Logfiles

The factual accuracy of this article or section is disputed.

Look for errors in the log files located at /var/log , as well as high priority errors in the systemd journal:

See systemd/Journal for more information.

See Xorg#Troubleshooting for information on where and how Xorg logs errors.

Backup

Create backups of important data at regular intervals. See Synchronization and backup programs for many alternative applications that may better suit your case. See Category:System recovery for other articles of interest.

It is encouraged to automate backups, see Autostarting#On time events.

Configuration files

Before editing any configuration files, create a backup so that you can revert to a working version in case of problems. Editors like vim and emacs can do this automatically, as well as tools like etckeeper which keep /etc in a version control system (VCS); see dotfiles#Tracking dotfiles directly with Git for more.

List of installed packages

Maintain a list of all installed packages so that if a complete re-installation is inevitable, it is easier to re-create the original environment.

Pacman database

Encryption metadata

System and user data

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.

Avoid certain pacman commands

Avoid doing partial upgrades. In other words, never run pacman -Sy ; instead, always use pacman -Syu .

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 Trusted Users 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 .
• 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.)

Always upgrade (with pacman -Syu ) before installing a package. 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 IgnorePkg and 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.

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.

Restart or reboot after upgrades

Upgrades are typically not applied to existing processes. You must restart processes to fully apply the upgrade.

The archlinux-contrib package provides a script called checkservices which runs pacdiff to merge .pacnew files then checks for processes running with outdated libraries and prompts the user if they want them to be restarted.

The kernel is particularly difficult to patch without a reboot. A reboot is always the most secure option, but if this is very inconvenient kernel live patching can be used to apply upgrades without a reboot.

Revert broken updates

If a package update is expected/known to cause problems, packagers will ensure that pacman displays an appropriate message when the package is updated. If experiencing trouble after an update, double-check pacman’s output by looking at /var/log/pacman.log .

At this point, only after ensuring there is no information available through pacman, there is no relative news on https://archlinux.org/, and there are no forum posts regarding the update, consider seeking help on the forum, over IRC, or by downgrading the offending package.

Check for orphans and dropped packages

After upgrading you may now have packages that are no longer needed or that are no longer in the official repositories.

Use pacman -Qtd to check for packages that were installed as a dependency but now, no other packages depend on them. If an orphaned package is still needed, it is recommended to change the installation reason to explicit. Otherwise, if the package is no longer needed, it can be removed.

Additionally, some packages may no longer be in the remote repositories, but they still may be on your local system. To list all foreign packages use pacman -Qm . Note that this list will include packages that have been installed manually (e.g., from the AUR). To exclude packages that are (still) available on the AUR, use the ancient-packages AUR tool.

Use the package manager to install software

Pacman does a much better job than you at keeping track of files. If you install things manually you will, sooner or later, forget what you did, forget where you installed to, install conflicting software, install to the wrong locations, etc.

• Install packages from the official repositories using the method in the Pacman#Installing packages section.
• If the program you desire is not available, check to see if someone has created a package in the AUR. Follow the method in that article for installation.
• Lastly, if the program you want is not in the official repositories or in the AUR, learn how to create a package for it.

Choose open-source drivers

Always try open source drivers before resorting to proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, try to choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at linux-drivers.org.

Be careful with unofficial packages

Use precaution when using packages from the AUR or an unofficial user repository. Most are supplied by regular users and thus may not have the same standards as those in the official repositories. Avoid AUR helpers which automate installation of AUR packages. Always check PKGBUILDs for sanity and signs of mistake or malicious code before building and/or installing the package.

To simplify maintenance, limit the amount of unofficial packages used. Make periodic checks on which are in actual use, and remove (or replace with their official counterparts) any others. See pacman/Tips and tricks#Maintenance for useful commands. Following system upgrade, use rebuild-detector to identify any unofficial packages that may need to be rebuilt.

Update the mirrorlist

Update pacman’s mirrorlist, as the quality of mirrors can vary over time, and some might go offline or their download rate might degrade.

See mirrors for details.

Clean the filesystem

When looking for files to remove, it is important to find the files that take up the most disk space. Programs that help with this are found in:

Package cache

Remove unwanted .pkg files from /var/cache/pacman/pkg/ to free up disk space.

Unused packages (orphans)

Remove unused packages from the system to free up disk space and simplify maintenance.

Old configuration files

Old configuration files may conflict with newer software versions, or corrupt over time. Remove unneeded configurations periodically, particularly in your home folder and

/.config . For similar reasons, be careful when sharing home folders between installations.

Look for the following folders:

/.config/ — where apps stores their configuration

/.cache/ — cache of some programs may grow in size

/.local/share/ — old files may be lying there

To keep the home directory clean from temporary files created at the wrong place, it is a good idea to manage a list of unwanted files and remove them regularly, for example with rmshit.py.

rmlint can be used to find and optionally remove duplicate files, empty files, recursive empty directories and broken symlinks.

Broken symlinks

Old, broken symbolic links might be sitting around your system; you should remove them. Examples on achieving this can be found here and here. However, you should not blindly delete all broken symbolic links, as some of them serve a purpose [1].

To quickly list all the broken symlinks of your system, use:

Then inspect and remove unnecessary entries from this list.

Tips and tricks

The following tips are generally not required, but certain users may find them useful.

Use proven software packages

Arch’s rolling releases can be a boon for users who want to try the latest features and get upstream updates as soon as possible, but they can also make system maintenance more difficult. To simplify maintenance and improve stability, try to avoid cutting edge software and install only mature and proven software. Such packages are less likely to receive difficult upgrades such as major configuration changes or feature removals. Prefer software that has a strong and active development community, as well as a high number of competent users, in order to simplify support in the event of a problem.

Avoid any use of the testing repository, even individual packages from testing. These packages are experimental and not suitable for a stable system. Similarly, avoid packages which are built directly from upstream development sources. These are usually found in the AUR, with names including things like: «dev», «devel», «svn», «cvs», «git», etc.

Install the linux-lts package

The linux-lts package is an alternative Arch kernel package, and is available in the core repository. This particular kernel version has long-term support (LTS) from upstream, including security fixes and some feature backports. It is useful if you prefer the stability of less-frequent kernel updates or if you want a fallback kernel in case a new kernel version causes problems.

Источник

pacman/Tips and tricks

For general methods to improve the flexibility of the provided tips or pacman itself, see Core utilities and Bash.

Contents

Maintenance

This article or section needs expansion.

Listing packages

With version

You may want to get the list of installed packages with their version, which is useful when reporting bugs or discussing installed packages.

• List all explicitly installed packages: pacman -Qe .
• List all packages in the package group named group : pacman -Sg group
• List all foreign packages (typically manually downloaded and installed or packages removed from the repositories): pacman -Qm .
• List all native packages (installed from the sync database(s)): pacman -Qn .
• List all explicitly installed native packages (i.e. present in the sync database) that are not direct or optional dependencies: pacman -Qent .
• List packages by regex: pacman -Qs regex .
• List packages by regex with custom output format (needs expac ): expac -s «%-30n %v» regex .

With size

Figuring out which packages are largest can be useful when trying to free space on your hard drive. There are two options here: get the size of individual packages, or get the size of packages and their dependencies.

Individual packages

The following command will list all installed packages and their individual sizes:

Packages and dependencies

To list package sizes with their dependencies,

• Install expac and run expac -H M ‘%m\t%n’ | sort -h .
• Run pacgraph with the -c option.

To list the download size of several packages (leave packages blank to list all packages):

To list explicitly installed packages not in the meta package base nor package group base-devel with size and description:

To list the packages marked for upgrade with their download size

By date

To list the 20 last installed packages with expac , run:

or, with seconds since the epoch (1970-01-01 UTC):

Not in a specified group, repository or meta package

List explicitly installed packages not in the base meta package:

List explicitly installed packages not in the base meta package or base-devel package group:

List all installed packages unrequired by other packages, and which are not in the base meta package or base-devel package group:

As above, but with descriptions:

List all installed packages that are not in the specified repository repo_name

List all installed packages that are in the repo_name repository:

List all packages on the Arch Linux ISO that are not in the base meta package:

Development packages

To list all development/unstable packages, run:

Browsing packages

To browse all installed packages with an instant preview of each package:

This uses fzf to present a two-pane view listing all packages with package info shown on the right.

Enter letters to filter the list of packages; use arrow keys (or Ctrl-j / Ctrl-k ) to navigate; press Enter to see package info under less.

To browse all packages currently known to pacman (both installed and not yet installed) in a similar way, using fzf, use:

The navigational keybindings are the same, although Enter will not work in the same way.

Listing files owned by a package with size

This one might come in handy if you have found that a specific package uses a huge amount of space and you want to find out which files make up the most of that.

Identify files not owned by any package

If your system has stray files not owned by any package (a common case if you do not use the package manager to install software), you may want to find such files in order to clean them up.

One method is to use pacreport —unowned-files as the root user from pacutils which will list unowned files among other details.

Another is to list all files of interest and check them against pacman:

Tracking unowned files created by packages

Most systems will slowly collect several ghost files such as state files, logs, indexes, etc. through the course of usual operation.

pacreport from pacutils can be used to track these files and their associations via /etc/pacreport.conf (see pacreport(1) § FILES ).

An example may look something like this (abridged):

Then, when using pacreport —unowned-files as the root user, any unowned files will be listed if the associated package is no longer installed (or if any new files have been created).

Additionally, aconfmgr ( aconfmgr-git AUR ) allows tracking modified and orphaned files using a configuration script.

Removing unused packages (orphans)

For recursively removing orphans and their configuration files:

If no orphans were found, the output is error: argument ‘-‘ specified with empty stdin . This is expected as no arguments were passed to pacman -Rns .

Removing everything but essential packages

If it is ever necessary to remove all packages except the essentials packages, one method is to set the installation reason of the non-essential ones as dependency and then remove all unnecessary dependencies.

First, for all the packages installed «as explicitly», change their installation reason to «as dependency»:

Then, change the installation reason to «as explicitly» of only the essential packages, those you do not want to remove, in order to avoid targeting them:

Finally, follow the instructions in #Removing unused packages (orphans) to remove all packages that have installation reason «as dependency».

Getting the dependencies list of several packages

Dependencies are alphabetically sorted and doubles are removed.

Listing changed backup files

The factual accuracy of this article or section is disputed.

If you want to back up your system configuration files, you could copy all files in /etc/ but usually you are only interested in the files that you have changed. Modified backup files can be viewed with the following command:

Running this command with root permissions will ensure that files readable only by root (such as /etc/sudoers ) are included in the output.

Back up the pacman database

The following command can be used to back up the local pacman database:

Store the backup pacman database file on one or more offline media, such as a USB stick, external hard drive, or CD-R.

The database can be restored by moving the pacman_database.tar.bz2 file into the / directory and executing the following command:

Check changelogs easily

When maintainers update packages, commits are often commented in a useful fashion. Users can quickly check these from the command line by installing pacolog AUR . This utility lists recent commit messages for packages from the official repositories or the AUR, by using pacolog

Installation and recovery

Alternative ways of getting and restoring packages.

Installing packages from a CD/DVD or USB stick

This article or section is a candidate for merging with #Custom local repository.

To download packages, or groups of packages:

Pacman, which will reference the host installation by default, will not properly resolve and download existing dependencies. In cases where all packages and dependencies are wanted, it is recommended to create a temporary blank DB and reference it with —dbpath :

Then you can burn the «Packages» folder to a CD/DVD or transfer it to a USB stick, external HDD, etc.

1. Mount the media:

2. Edit pacman.conf and add this repository before the other ones (e.g. extra, core, etc.). This is important. Do not just uncomment the one on the bottom. This way it ensures that the files from the CD/DVD/USB take precedence over those in the standard repositories:

3. Finally, synchronize the pacman database to be able to use the new repository:

Custom local repository

Use the repo-add script included with pacman to generate a database for a personal repository. Use repo-add —help for more details on its usage. A package database is a tar file, optionally compressed. Valid extensions are .db or .files followed by an archive extension of .tar, .tar.gz, .tar.bz2, .tar.xz, .tar.zst, or .tar.Z. The file does not need to exist, but all parent directories must exist.

To add a new package to the database, or to replace the old version of an existing package in the database, run:

The database and the packages do not need to be in the same directory when using repo-add, but keep in mind that when using pacman with that database, they should be together. Storing all the built packages to be included in the repository in one directory also allows to use shell glob expansion to add or update multiple packages at once:

If you are looking to support multiple architectures then precautions should be taken to prevent errors from occurring. Each architecture should have its own directory tree:

The repo-add executable checks if the package is appropriate. If this is not the case you will be running into error messages similar to this:

repo-remove is used to remove packages from the package database, except that only package names are specified on the command line.

Once the local repository database has been created, add the repository to pacman.conf for each system that is to use the repository. An example of a custom repository is in pacman.conf . The repository’s name is the database filename with the file extension omitted. In the case of the example above the repository’s name would simply be repo. Reference the repository’s location using a file:// url, or via FTP using ftp://localhost/path/to/directory.

If willing, add the custom repository to the list of unofficial user repositories, so that the community can benefit from it.

Network shared pacman cache

This article or section is a candidate for merging with Package_Proxy_Cache.

If you happen to run several Arch boxes on your LAN, you can share packages so that you can greatly decrease your download times. Keep in mind you should not share between different architectures (i.e. i686 and x86_64) or you will run into problems.

Read-only cache

If you are looking for a quick solution, you can simply run a standalone webserver, e.g. darkhttpd , which other computers can use as a first mirror:

You could also run darkhttpd as a systemd service for convenience. Just add this server at the top of your /etc/pacman.d/mirrorlist in client machines with Server = http://mymirror:8080 . Make sure to keep your mirror updated.

If you are already running a web server for some other purpose, you might wish to reuse that as your local repository server instead of darkhttpd. For example, if you already serve a site with nginx, you can add an nginx server block listening on port 8080:

Remember to restart nginx after making this change.

Whichever web server you use, remember to open port 8080 to local traffic (and you probably want to deny anything not local). For example, if using iptables, add -s 192.168.0.0/16 -p tcp —dport 8080 -j ACCEPT to your ruleset (adjust for your LAN subnet if necessary).

Overlay mount of read-only cache

It is possible to use one machine on a local network as a read-only package cache by overlay mounting its /var/cache/pacman/pkg directory. Such a configuration is advantageous if this server has installed on it a reasonably comprehensive selection of up-to-date packages which are also used by other boxes. This is useful for maintaining a number of machines at the end of a low bandwidth upstream connection.

As an example, to use this method:

Note concerning overlay: The working directory must be an empty directory on the same mounted device as the upper directory.

After this, run pacman using the option —cachedir /tmp/pacman_pkg , e.g.:

Distributed read-only cache

There are Arch-specific tools for automatically discovering other computers on your network offering a package cache. Try pacredir , pacserve, pkgdistcache AUR , or paclan AUR . pkgdistcache uses Avahi instead of plain UDP which may work better in certain home networks that route instead of bridge between WiFi and Ethernet.

Historically, there was PkgD and multipkg, but they are no longer maintained.

Read-write cache

In order to share packages between multiple computers, simply share /var/cache/pacman/ using any network-based mount protocol. This section shows how to use shfs or SSHFS to share a package cache plus the related library-directories between multiple computers on the same local network. Keep in mind that a network shared cache can be slow depending on the file-system choice, among other factors.

First, install any network-supporting filesystem packages: shfs-utils , sshfs , curlftpfs , samba or nfs-utils .

Then, to share the actual packages, mount /var/cache/pacman/pkg from the server to /var/cache/pacman/pkg on every client machine.

two-way with rsync

Another approach in a local environment is rsync. Choose a server for caching and enable the Rsync#rsync daemon. On clients synchronize two-way with this share via the rsync protocol. Filenames that contain colons are no problem for the rsync protocol.

Draft example for a client, using uname -m within the share name ensures an architecture-dependent sync:

Dynamic reverse proxy cache using nginx

nginx can be used to proxy package requests to official upstream mirrors and cache the results to the local disk. All subsequent requests for that package will be served directly from the local cache, minimizing the amount of internet traffic needed to update a large number of computers.

In this example, the cache server will run at http://cache.domain.example:8080/ and store the packages in /srv/http/pacman-cache/ .

Install nginx on the computer that is going to host the cache. Create the directory for the cache and adjust the permissions so nginx can write files to it:

Use the nginx pacman cache config as a starting point for /etc/nginx/nginx.conf . Check that the resolver directive works for your needs. In the upstream server blocks, configure the proxy_pass directives with addresses of official mirrors, see examples in the config file about the expected format. Once you are satisfied with the configuration file start and enable nginx.

In order to use the cache each Arch Linux computer (including the one hosting the cache) must have the following line at the top of the mirrorlist file:

Pacoloco proxy cache server

Pacoloco is an easy-to-use proxy cache server for pacman repositories. It also allows automatic prefetching of the cached packages.

It can be installed as pacoloco . Open the configuration file and add pacman mirrors:

Restart pacoloco.service and the proxy repository will be available at http://myserver:9129/repo/mycopy .

Flexo proxy cache server

Flexo is yet another proxy cache server for pacman repositories. Flexo is available as flexo-git AUR . Once installed, start the flexo.service unit.

Flexo runs on port 7878 by default. Enter Server = http://myserver:7878/$repo/os/$arch to the top of your /etc/pacman.d/mirrorlist so that pacman downloads packages via Flexo.

Synchronize pacman package cache using synchronization programs

Use Syncthing or Resilio Sync to synchronize the pacman cache folders (i.e. /var/cache/pacman/pkg ).

Preventing unwanted cache purges

By default, pacman -Sc removes package tarballs from the cache that correspond to packages that are not installed on the machine the command was issued on. Because pacman cannot predict what packages are installed on all machines that share the cache, it will end up deleting files that should not be.

To clean up the cache so that only outdated tarballs are deleted, add this entry in the [options] section of /etc/pacman.conf :

Recreate a package from the file system

To recreate a package from the file system, use fakepkg AUR . Files from the system are taken as they are, hence any modifications will be present in the assembled package. Distributing the recreated package is therefore discouraged; see ABS and Arch Linux Archive for alternatives.

List of installed packages

Keeping a list of all the explicitly installed packages can be useful, to backup a system for example or speed up installation on a new system:

To keep an up-to-date list of explicitly installed packages (e.g. in combination with a versioned /etc/ ), you can set up a hook. Example:

Install packages from a list

To install packages from a previously saved list of packages, while not reinstalling previously installed packages that are already up-to-date, run:

However, it is likely foreign packages such as from the AUR or installed locally are present in the list. To filter out from the list the foreign packages, the previous command line can be enriched as follows:

Eventually, to make sure the installed packages of your system match the list and remove all the packages that are not mentioned in it:

Listing all changed files from packages

If you are suspecting file corruption (e.g. by software/hardware failure), but are unsure if files were corrupted, you might want to compare with the hash sums in the packages. This can be done with pacutils :

Reinstalling all packages

To reinstall all native packages, use:

Foreign (AUR) packages must be reinstalled separately; you can list them with pacman -Qqm .

Pacman preserves the installation reason by default.

Restore pacman’s local database

Recovering a USB key from existing install

If you have Arch installed on a USB key and manage to mess it up (e.g. removing it while it is still being written to), then it is possible to re-install all the packages and hopefully get it back up and working again (assuming USB key is mounted in /newarch )

Viewing a single file inside a .pkg file

For example, if you want to see the contents of /etc/systemd/logind.conf supplied within the systemd package:

Or you can use vim to browse the archive:

Find applications that use libraries from older packages

Even if you installed a package the existing long-running programs (like daemons and servers) still keep using code from old package libraries. And it is a bad idea to let these programs running if the old library contains a security bug.

Here is a way how to find all the programs that use old packages code:

It will print running program name and old library that was removed or replaced with newer content.

Installing only content in required languages

Many packages attempt to install documentation and translations in several languages. Some programs are designed to remove such unnecessary files, such as localepurge AUR , which runs after a package is installed to delete the unneeded locale files. A more direct approach is provided through the NoExtract directive in pacman.conf , which prevent these files from ever being installed.

The example below installs English (US) files, or none at all:

Performance

Download speeds

When downloading packages pacman uses the mirrors in the order they are in /etc/pacman.d/mirrorlist . The mirror which is at the top of the list by default however may not be the fastest for you. To select a faster mirror, see Mirrors.

Pacman’s speed in downloading packages can also be improved by using a different application to download packages, instead of pacman‘s built-in file downloader, or by enabling parallel downloads.

In all cases, make sure you have the latest pacman before doing any modifications.

Powerpill

Powerpill is a pacman wrapper that uses parallel and segmented downloading to try to speed up downloads for pacman.

This is also very handy if you need more powerful proxy settings than pacman‘s built-in capabilities.

To use wget , first install the wget package then modify /etc/pacman.conf by uncommenting the following line in the [options] section:

Instead of uncommenting the wget parameters in /etc/pacman.conf , you can also modify the wget configuration file directly (the system-wide file is /etc/wgetrc , per user files are $HOME/.wgetrc ).

aria2

aria2 is a lightweight download utility with support for resumable and segmented HTTP/HTTPS and FTP downloads. aria2 allows for multiple and simultaneous HTTP/HTTPS and FTP connections to an Arch mirror, which should result in an increase in download speeds for both file and package retrieval.

Install aria2 , then edit /etc/pacman.conf by adding the following line to the [options] section:

See aria2c(1) § OPTIONS for used aria2c options.

• -d, —dir : The directory to store the downloaded file(s) as specified by pacman.
• -o, —out : The output file name(s) of the downloaded file(s).
• %o : Variable which represents the local filename(s) as specified by pacman.
• %u : Variable which represents the download URL as specified by pacman.

Other applications

There are other downloading applications that you can use with pacman. Here they are, and their associated XferCommand settings:

• snarf : XferCommand = /usr/bin/snarf -N %u
• lftp : XferCommand = /usr/bin/lftp -c pget %u
• axel : XferCommand = /usr/bin/axel -n 2 -v -a -o %o %u
• hget : XferCommand = /usr/bin/hget %u -n 2 -skip-tls false (please read the documentation on the Github project page for more info)
• saldl : XferCommand = /usr/bin/saldl -c6 -l4 -s2m -o %o %u (please read the documentation on the project page for more info)

Источник