Arch terminology

From ArchWiki
Revision as of 10:13, 14 April 2006 by Pressh (talk | contribs) (udev)
Jump to: navigation, search

Arch Terminology/Jargon for newbies

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.


The Arch Build System (ABS for short) is useful to

  • Make new packages of software for which no packages are yet available
  • Customize/Modify existing packages to fit your needs (enabling or disabling options)
  • Re-build your entire system using your compiler flags, "a la gentoo" (And getting kernel modules working with your custom kernel!)

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

For more information see the ABS wiki


The ArchLinux User-Community Repository (AUR) is a community driven repository for Arch users. The AUR was initially conceived to organize the sharing of PKGBUILDs amongst the wider community and to expedite the inclusion of popular user-contributed packages into the [current] and [extra] repos via the AUR [community] repo.

It is called to be the birthplace of Arch's new packages. This is because in the AUR, the users contribute their own packages. The AUR community votes for or against them, and eventually, once a package has been voted high enough, a AUR Trusted User takes it to the [community] repository, which is accessible via pacman and ABS.

You can access the ArchLinux User-Community Repository here



Trusted User. This is someone who the other TU's have voted into place to manage the AUR and the [community] repository.

Trusted Users have the ability to mark a package as safe on the AUR, and if it has been voted as popular, move it into the [community] repository.

Trusted users follow the [AUR Trusted User Guidelines] and TU by-laws



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.

To access the community repository, uncomment it in /etc/pacman.conf.


custom/user repository














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, wget, 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 buildtime 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.



The Pacman package manager is one of the great highlights of Arch Linux. It combines a simple binary package format with an easy-to-use build system (see ABS). Pacman makes it possible to easily manage and customize packages, whether they be from the official Arch repositories or the user's own creations. The repository system allows users to build and maintain their own custom package repositories, which encourages community growth and contribution (see AUR).

Pacman can keep a system up to date by synchronizing package lists with the master server, making it a breeze for the security-conscious system administrator to maintain. This server/client model also allows you to download/install packages with a simple command, complete with all required dependencies (similar to Debian's apt-get).

NB: Pacman was written and is being maintained by Judd Vinet, the creator of Arch Linux. But it is used as a package management tool by other distros as well, such as FrugalWare (see also 1), Rubix, UfficioZero (in Italian, based on Ubuntu!!), and of course ArchLinux-derivatives such as Archie and AEGIS.





Read The Fucking Manual. This is 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

man program

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 do as above, and read the manual page:

  • Read the program man page, at a command line
man program-name
  • Search the wiki
  • Search the forum
  • Search Google



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 or removed form 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.



This is a very simple script that allows you to easily update your CVS and SVN packages without having to edit the PKGBUILDs manually to enter the date or revision number.

Simply run this script rather than makepkg in the build dir. This script completely removes the need for backtick execution to set the date or tag version in PKGBUILDs.

More detailed information can be found here