Devland
From ArchWiki
Summary
Arch Linux has been described as the perfect GNU/Linux distro. However, a perfect distro is always evolving. This document describes some of the issues developers are currently working on.
The goal of this document is to help users become aware of what the developers are doing and where Arch Linux is headed. Some of these projects are major issues that need addressing; others are enhancements that users may not be aware of.
Introduction
The purpose of this document is to help users understand some of the developer plans for the future. It also addresses the developer's stand on some issues that need addressing.
At the moment, a lot of these plans are sore points within the user community, although the developers are more or less in agreement on most of them. Others are new project ideas that developers are working on to make Arch Linux an even better distro.
Arch Linux Philosophy
The philosophy behind Arch Linux, and driving force for the developers is to keep it simple. The developers do not wish to spend a lot of time deriving complicated ways of doing simple tasks. This is why all Arch configuration is done through configuration files, why only up-to-date systems are supported, etc. It is the reason for many of the decisions described below.
This driving philosophy gives more power to the users. You are in charge of your system. The purpose of this GNU/Linux distribution is not to hold your hand or to do things for you. It is to empower you.
As a distribution, Arch Linux doesn't need to do a lot of things, but the things it does do it does well. It is not the purpose of a distribution to provide packages; what a distribution must provide is a package management system. Arch excels in this regard, giving you pacman for binary packages and the Arch Build System for source-based package creation. Arch provides a simple and powerful boot-up routine and initscripts. Other than this, most configuration is left up to program developers. If the developer created a program to run from a single directory, it is placed in /opt. If it was meant to be spread across directories in /usr/, then it is packaged that way on Arch. This keeps things simple, both for the developers and for the users. Now the files you need to configure or use are located where the program's documentation says they are located, not where the distribution says they should be located.
The typical way to use Arch is to use pacman to install all packages unless there is no package available, in which case you can build your own package using the Arch Build System. Many user-contributed packages are available in the Arch User Repository You are expected to keep your system up to date with pacman -Syu, rather than selectively upgrading packages. Even use of IgnorePkg in /etc/pacman.conf is discouraged.
You may diverge from this typical usage as you wish; just be warned that there is a greater chance that things will not work as intended and that it could break your system. The majority of complaints happen when selective upgrading or unusual compilation is performed.
More information about this can be found at The Arch Way.
Arch User Repository
Packages that are not stored in the official repositories ([core], [extra], or [testing]) may be available in AUR. The AUR serves two purposes.
The first is to allow Trusted Users to maintain a repository of packages known as [community]. Trusted Users are selected democratically from the Arch Linux user community based on their reputation for creating high-quality packages and other criteria. Packages in [community] can be downloaded using pacman by uncommenting its section in pacman.conf. These packages are packages used by enough Arch users to warrant easy access using pacman -S, but not popular enough for inclusion in the official repositories. If packages become mainstream, they are eventually migrated from [community] to [extra].
The second purpose of AUR is to allow users to submit and maintain unsupported packages. These packages cannot be installed using pacman, but can be built using makepkg. It is important to understand that packages in unsupported have not been checked for security. Make sure you check the PKGBUILD before installing. Unsupported packages are thought of as packages that are used by only a few users. If they become popular enough, they are adopted by a Trusted User and included in the [community] repository.
You can find the AUR at http://aur.archlinux.org/index.php.
AUR Voting
The AUR web interface has a mechanism to allow users to vote for packages. There has been some confusion as to what this mechanism means. It is NOT a measure of quality. Rather, when voting for a package in AUR, you are saying that you wish to see that package in a repository. It is a measure of popularity. Packages in unsupported that receive enough votes are graduated to the [community] repository by a TU. This means that you will be able to install the package with pacman, rather than having to build it yourself. Packages in [community] that receive enough votes will be graduated to one of the official repositories (usually [extra]).
Use of Testing Repository
Major updates that are expected to cause problems are listed in the [testing] repository for the bold and daring to test and bug-report before the packages are migrated to the official repositories.
Several people have suggested submitting all packages to [testing] instead of just major upgrades. This idea has been considered, but developers have opted to stay with the current system for reasons of simplicity and for quick releases of packages not expected to cause problems. This question has been decided and needs no further discussion.
There also seems to be some confusion as to how [testing] is meant to be used. Arch's [testing] repository is NOT meant to allow users to access bleeding-edge packages. Rather, [testing] is a repository for packages that we suspect are broken and need fixing. [Testing] should be used only by people who wish to help us track down and fix bugs before packages are released to [core] or [extra].
Number of Repositories
It has been suggested that Arch Linux change the number of repositories; some people believe there should be more, others requesting fewer. The current system separates the official repositories (core, extra, and testing) from the unofficial ones (mostly the various user-run repositories).
Developers have decided that there should definitely not be an increase in the number of repositories, especially official ones. Users are finding the system somewhat confusing as it is.
There is still some discussion over decreasing the number of repositories. It is unlikely that official repositories will be decreased, as each one serves a specific purpose. However, the Trusted User Repositories have been consolidated into a single repository ([community])as part of the conversion to the AUR.
It has also been suggested that there be more snapshot repositories, especially a snapshot of the extra repository at time of release. Arch is designed as a rolling-release system, and support is provided only for the current repositories (including extra).
Further, Arch does not currently have enough developers to maintain an extra snapshot. It would require many backports and security bug fixes in order to be of any use. Users are encouraged to keep their systems up to date using the pacman -Syu command on a regular basis.
Developers are still discussing the possibility of supporting a stable snapshot repository sometime in the future. This will require more developers and is not likely to occur until the 1.0 release at the very earliest. Some independent users are also investigating setting up an unofficial snapshot repository.
Other Package Formats
There has been some talk of supporting a tool that converts from other package formats (such as RPM, deb, ebuild, slack) to the pacman format.
Though users are welcome to create and share such tools, Arch is not likely to officially support other packages. There are several reasons for this.
First, it is very easy to create packages for Arch Linux using Arch Build System and makepkg. It is usually less work to compile a program from scratch than to use another distribution's binary format.
Second, Arch packages are meant to be i686-optimized so that they run quickly on this architecture. Most other formats are compiled for i586 at best, usually i386. Thus, packages should be recompiled to take advantage of these optimizations anyway.
Third, though pacman packages are in the simpler format, some package formats do not migrate well to it. It is less work to translate the package by hand.
Fourth, packages compiled elsewhere may not last long with Arch's rolling-release system. Gcc and libc, for example, are updated frequently on Arch, as compared to many other distributions. Packages compiled on older versions of gcc and libc will often conflict with Arch.
Different Package Distribution
It has been suggested several times that Arch use bzip2 instead of gzip to compress packages. This would save a small amount of space, resulting in smaller downloads, and less bandwidth usage on the FTP servers.
The smaller download would be appreciated only by dialup users, as the difference between bzip2 and gzip is not that great. Further, bzip2 takes a lot longer than gzip to decompress; this would actually make it take more time to download and install a package in many cases (especially for those on broadband).
Another frequent suggestion is to use binary diffs for packages. This could reduce download requirements on the largest packages. The drawback is that it may be insecure, both in that it might be possible to hack the diff and in that the diffs may not apply perfectly in all situations. Another problem is similar to the bzip2 issue; it takes more time to apply the diff. Probably the biggest reason binary diffs are not likely to be supported in the near future, however, is the massive amount of work that would be required to implement it.
Dale has done some experimenting with binary diffs, and discovered that the bandwidth saved is not worth the effort. He notes that a binary diff on entire packages is only about 10% smaller than the new package, and that some diffs are actually larger than the new package. He suggests that using a binary diff on each file in the package, as opposed to on the complete compressed package, would likely improve the results drastically, but that we do not currently have enough developer support to take on such a task.
Another Dale has done some experimenting with xdelta binary diffs. Across 17 packages the total diff size was 7% of the full size of the packages. The size reduction ranged from 99% to 41%. On the forum you can view the statistics.
Transaction Support/Reverting
Long on the pacman to-do list is support for transactions; that is, the ability to revert to earlier versions of packages (rollback). Occasionally, a package upgrade unexpectedly makes a mess of many people's systems and the quickest (and sometimes the only) way to fix it is to revert to the earlier version.
Though nothing has been implemented yet, this feature will be included in pacman eventually. There is currently no word as to when; it is probably a long-term item.
It is still possible to revert packages by using the CVS interface and makepkg. See this FAQ for details.
DE/WM Menus
Developers are working on a basic menuing system for common GUI apps. This system will create and update default menus whenever common GUI applications are installed.
The menus will be automatically updated for each of the desktop environments and window managers provided by Arch, taking a load off the system administrator and user.
Pacman Backend
Aurelien has finished an implementation draft of a pacman back-end design. The design seems solid, and he expects to have the implementation starting point finished by mid-October. He still needs to implement a few remaining options (notably upgrade and sysupgrade). At that time, he will be ready to share the code with other developers in alpha release. A final release date is, as yet, undetermined.
Libraryizing pacman in this way will allow other programs (such as GUI front-ends) to easily interface with the pacman functions. This is much more efficient and extensible than making calls to the pacman program itself. The CLI front-end will still, of course, be available.
Non-free Packages
Some users request that non-free packages not be included in the Arch Linux repositories, while others suggest they be placed in their own repository.
The developers don't want to increase the number of repositories needlessly. And they do not want to leave out potentially useful packages. The general stand on non-free packages is that they should be included if there is not a better free version.
The issue is further complicated by the conflicting definitions of the word free. Some people think only GPL code should be included, while others believe that BSD-style licenses should be supported as well. The myriad open-source licenses currently available make it difficult to include or exclude the right packages.
PKGBUILDs have recently been given a new field called LICENSE. This field can be used to distinguish between free and non-free packages eventually, once the majority of PKGBUILDs support the new field. In the meantime, if users are that worried about whether they have non-free packages installed on their system, they will have to watch out for their installation whenever they install dependencies.
License Field in PKGBUILDS
There has been a LICENSE field available in PKGBUILDs for a long time, yet usage of it has been discouraged as we hadn't settled on its usage. As of pacman 2.9.7, the following rules will be enforced in creating packages:
- A licenses package will be created that stores common licenses in /usr/share/licenses/common (i.e. /usr/share/licenses/common/GPL). If a package is licensed under one of these licenses, the licenses variable will be set to the directory's name.
- If a license is not included in the licenses package, two things will be done: 1) include license file(s) in /usr/share/licenses/<pkgname>, 2) add 'custom' to the licenses array. Optionally, you can replace 'custom' with 'custom:<name of license>'.
- Once a license is used in two or more packages, it becomes common (assuming it's in an official repository or community).
- BSD is a special case. For the sake of the license variable, it's treated like a common license (license=("BSD")). For the sake of the filesystem, it's a custom license, because each one has its own copyright line.
- Multiple entries in the license array are OR'd together as the majority of them apply in different cases, as opposed to applying at the same time.