- 1 Arch Terminology/Jargon for newbies
- 1.1 ABS
- 1.2 AUR
- 1.3 PKGBUILD
- 1.4 TU
- 1.5 TUR
- 1.6 community/[community]
- 1.7 current/[current]
- 1.8 custom/user repository
- 1.9 developer
- 1.10 devfs
- 1.11 /etc/network-profiles
- 1.12 /etc/rc.conf
- 1.13 /etc/rc.d
- 1.14 /etc/rc.local
- 1.15 extra/[extra]
- 1.16 hotplug
- 1.17 hwd
- 1.18 hwdetect
- 1.19 initramfs
- 1.20 initrd
- 1.21 makepkg
- 1.22 namcap
- 1.23 package
- 1.24 pacman
- 1.25 pacman.conf
- 1.26 release/[release]
- 1.27 repository/repo
- 1.28 rtfm
- 1.29 testing/[testing]
- 1.30 udev
- 1.31 unstable/[unstable]
- 1.32 versionpkg
- 1.33 wiki
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 page
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.
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.
Anyone can create a repo and put it online so other users can use it. The repository has the precompiled packages of one or (usually) more PKGBUILD's. To create a repository, you need a pacman compatible database file for your packages. The DB file is created with gensync. When you've got a set of packages and a database file, you can put them online (HTTP or FTP) and everyone will be able to use it by adding it as a regular repository.
The Device File System. DevFS handles, dynamically, the creation, deletion and permission management of device nodes in the /dev directory. It was the default kernel device manager in Arch Linux until release 0.7. Now DevFS is deprecated and in the process of being removed from the Linux kernel. DevFS has been superseded by udev.
Note that Arch installation CDs prior to 0.7.1 use the devfs naming scheme when creating /etc/fstab entries. See DevFS to Udev.
In this, you can create various network configurations.
This is very usefull for laptop users that switch networks very often, for example between a home and an office network.
Additionally it can be used with wpa-supplicant that can manage all of you wireless networks. For each configuration you need to make a configuration file. The easiest way to do this, is by copying the template. After you are done with this, you need to enable these in /etc/rc.conf
After applying changes, you should restart your network by using, as root,
/etc/rc.conf is the main system configuration file for Arch Linux. It allows you to set your keyboard, timezone, hostname, network, daemons to run and modules to load at bootup, profiles, and more. Detailed description of the configuration options is given here: http://archlinux.org/archdoc.html#cfile1
/etc/rc.d is a directory that contains the scripts that handle starting and stopping of services. On every boot, the services that are present in the DAEMONS= array in /etc/rc.conf are started by running the corresponding scripts in /etc/rc.d.
It is also possible to control the services from the command line (as root), e.g.,
would start the CUPS daemon. Typical arguments for the scripts are start, stop and restart.
This script is run at the end of every boot. It is intended for miscellaneous commands that you might want to execute before the login prompt. It is not recommended to add any services or settings in /etc/rc.local that could be started or set from /etc/rc.conf instead.
The special file /dev/initrd is a read-only block device. Device /dev/initrd is a RAM disk that is initialized (e.g. loaded) by the boot loader before the kernel is started. The kernel then can use the block device /dev/initrd's contents for a two phased system boot-up.
In the first boot-up phase, the kernel starts up and mounts an initial root file-system from the contents of /dev/initrd (e.g. RAM disk initialized by the boot loader). In the second phase, additional drivers or other modules are loaded from the initial root device's contents. After loading the additional modules, a new root file system (i.e. the normal root file system) is mounted from a different device.
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.
namcap is a package analysis utility that looks for problems with archlinux 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're doing then you can leave them. Information (designated 'I:') are only shown when you use the info arguement. Information messages give information that might be helpful but isn't anything that needs changing.
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. 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 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
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
- 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