Arch terminology

This page is intended to be a page to demystify common terms used among the Arch Linux community. Feel free to add or modify any terms, but please use that particular section's edit option. If you decide to add one, please put it in alphabetical order.


ABS stands for Arch Build System and can be used for:

  • Making new packages for software that has no packages available yet
  • Customizing/modifying existing packages to fit your needs:
    • Enabling/disabling build-time options
    • Applying source changes via patches
  • Re-building your entire system using your compiler flags, "à la Gentoo"
  • Getting kernel modules working with your custom kernel

ABS is not necessary to use Arch Linux, but it is useful.

Arch Linux

Arch should be referred to as:

  • Arch Linux
  • Arch (Linux implied)
  • archlinux (UNIX name)

Archlinux, ArchLinux, archLinux, aRcHlInUx, etc. are all weird, and weirder mutations.

Officially, the 'Arch' in "Arch Linux" is pronounced /ɑːrtʃ/ as in an "archer"/bowman, or "arch-nemesis", and not as in "ark" or "archangel".

Arch Linux Archive

The Arch Linux Archive (a.k.a ALA), formerly known as Arch Linux Rollback Machine (a.k.a ARM), stores official repositories snapshots, ISO images and bootstrap tarballs across time.


The Arch User Repository (AUR) is a community-driven repository for Arch users. It contains package descriptions (PKGBUILDs) that allow you to compile a package from source with makepkg and then install it via pacman. The AUR was created to organize and share new packages from the community and to help expedite popular packages' inclusion into the community repository.

A good number of new packages that enter the official repositories start in the AUR. In the AUR, users are able to contribute their own package builds (PKGBUILD and related files). The AUR community has the ability to vote for or against packages in the AUR. If a package becomes popular enough — provided it has a compatible license and good packaging technique — it may be entered into the community repository (directly accessible by pacman or abs).

You can access the Arch Linux User Community Repository here.


Bulletin board system, but in Arch's case, it is just the support forum located here.


The community repository is where pre-built packages are made available by Trusted Users. A majority of the packages in community come from the AUR.


The core repository contains the bare packages needed for an Arch Linux system. core has everything needed to get a working command-line system.

custom/user repository

Anyone can create a repository and put it online for other users. To create a repository, you need a set of packages and a pacman-compatible database file for your packages. Host your files online and everyone will be able to use your repository by adding it as a regular repository.

See Custom local repository.


Half-gods working to improve Arch for no financial gain. Developers are outranked only by our gods, Judd Vinet and Aaron Griffin, who in turn are outranked by tacos.


Arch's official package set is fairly streamlined, but we supplement this with a larger, more complete extra repository that contains a lot of the stuff that never made it into our core package set. This repository is constantly growing with the help of packages submitted from our strong community. This is where desktop environments, window managers and common programs are found.


See mkinitcpio.


Obsolete. Nowadays often used as a synonym for initramfs.


Acronym of Keep It Simple, Stupid. Simplicity is a main principle Arch Linux tries to achieve.


makepkg will build packages for you. makepkg will read the metadata required from a PKGBUILD file. All it needs is a build-capable Linux platform, curl, and some build scripts. The advantage to a script-based build is that you only really do the work once. Once you have the build script for a package, you just need to run makepkg and it will do the rest: download and validate source files, check dependencies, configure the build time settings, build the package, install the package into a temporary root, make customizations, generate meta-info, and package the whole thing up for pacman to use.


namcap is a package analysis utility that looks for problems with Arch Linux packages or their PKGBUILD files. It can apply rules to the file list, the files themselves, or individual PKGBUILD files.

Rules return lists of messages. Each message can be one of three types: error, warning, or information (think of them as notes or comments). Errors (designated by 'E:') are things that namcap is very sure are wrong and need to be fixed. Warnings (designated by 'W:') are things that namcap thinks should be changed but if you know what you are doing then you can leave them. Information (designated 'I:') are only shown when you use the info argument. Information messages give information that might be helpful but is not anything that needs changing.


See pacman#Installing packages.

Note: Different GNU/Linux distributions use different packages and package managers, meaning that you cannot use pacman to install a Debian package on Arch.

Package maintainer

The role of a package maintainer is to update packages as new versions become available upstream and to field support questions relating to bugs in said packages. The term applies to:

  • Developers who maintain packages in the official repositories (core, extra, or testing).
  • Trusted Users who maintain packages in the community repository.
  • Normal users who maintain packages in the AUR.

The maintainer of a package is the person currently responsible for the package. Previous maintainers should be listed as contributors in the PKGBUILD along with others who have contributed to the package.


See pacman.


PKGBUILDs are small scripts that are used to build Arch Linux packages. See Creating packages for more detail.


The repository has the pre-compiled packages of one or (usually) more PKGBUILDs. Official repositories are split into different parts for easy maintenance. Pacman uses these repositories to search for packages and install them. A repository can be local (i.e. on your own computer) or remote (i.e. the packages are downloaded before they are installed).


RTFM stands for "Read The Friendly Manual". This simple message is replied to a lot of new Linux/Arch users who ask about the functionality of a program when it is clearly defined in the program's manual.

It is often used when a user fails to make any attempt to find a solution to the problem themselves. If someone tells you this, they are not trying to offend you; they are just frustrated with your lack of effort.

The best thing to do if you are told to do this is to read the manual page.

  • To read the program manual page for a particular program named as PROGRAM-NAME, type this at the command line: man PROGRAM-NAME.

If you do not find the answer to your question in the program manual, there are more ways to find the answer. You can:


This is the repository where major packages/updates to packages are kept prior to release into the main repositories, so they can be bug tested and upgrade issues can be found. It is disabled by default but can be enabled in /etc/pacman.conf

The Arch Way

The unofficial term traditionally used to refer to the main Arch Linux principles.

TU, Trusted User

A trusted user is someone who maintains the AUR and the [community] repository. Trusted Users may move a package into the [community] repository if it has been voted as popular. TUs are appointed by a majority vote by the existing TUs.

Trusted users follow the AUR Trusted User guidelines and TU by-laws


udev provides a dynamic device directory containing only the files for actually present devices. It creates or removes device node files in the /dev directory, or it renames network interfaces.

Usually udev runs as udevd(8) and receives uevents directly from the kernel if a device is added/removed to/from the system.

If udev receives a device event, it matches its configured rules against the available device attributes provided in sysfs to identify the device. Rules that match may provide additional device information or specify a device node name and multiple symlink names and instruct udev to run additional programs as part of the device event handling.


Our wiki is a place to find documentation about Arch Linux. Anyone can contribute to the documentation.

gollark: Does Xander *need* 3TB of storage?
gollark: <@!202992030685724675> The reactor is done!
gollark: Unlike *someone*, I actually have mitigations on.
gollark: ```Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr p ge mca cmov pat pse36 clflush dts acpi mmx fxsr ss e sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm c onstant_tsc art arch_perfmon pebs bts rep_good nop l xtopology nonstop_tsc cpuid aperfmperf tsc_known _freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4 _2 x2apic movbe popcnt tsc_deadline_timer aes xsav e avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_ fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsb ase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mp x rdseed adx smap clflushopt intel_pt xsaveopt xsa vec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp _notify hwp_act_window hwp_epp md_clear flush_l1d```
gollark: Architecture: x86_64CPU op-mode(s): 32-bit, 64-bitByte Order: Little EndianAddress sizes: 39 bits physical, 48 bits virtualCPU(s): 4On-line CPU(s) list: 0-3Thread(s) per core: 2Core(s) per socket: 2Socket(s): 1NUMA node(s): 1Vendor ID: GenuineIntelCPU family: 6Model: 142Model name: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHzStepping: 9CPU MHz: 861.413CPU max MHz: 3100.0000CPU min MHz: 400.0000BogoMIPS: 5426.00Virtualization: VT-xL1d cache: 64 KiBL1i cache: 64 KiBL2 cache: 512 KiBL3 cache: 3 MiBNUMA node0 CPU(s): 0-3Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache f lushes, SMT vulnerableVulnerability Mds: Mitigation; Clear CPU buffers; SMT vulnerableVulnerability Meltdown: Mitigation; PTIVulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccompVulnerability Spectre v1: Mitigation; __user pointer sanitizationVulnerability Spectre v2: Mitigation; Full generic retpoline, IBRS_FW, STIBP conditional, RSB filling
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.