Arch Linux is a lightweight and flexible Linux distribution that offers rolling releases of packages. It aims for simplicity in package building and minimal customization from upstream sources. The community is involved in package creation and management through the Arch User Repository and Trusted Users roles. Future plans include continuing to provide timely package updates, expanding architecture support, and further simplifying the filesystem structure.

1. a simple, rolling-release
distribution
Tom Gundersen
teg@jklm.no

2. Overview
●
Arch Linux
●
Packaging
●
The community
●
Future plans

3. Arch Linux - Simplicity
●
Creating and building packages is easy
●
Divergence from upstream is minimal
●
Choice for its own sake is avoided
●
The workings of the system is not hidden
from the user

4. Arch Linux – Rolling Release
●
Ship the latest stable release of our
packages (there are exceptions)
●
Don't necessarily be the very first to switch
to new or experimental technologies or
introduce new packages to our repositories

5. Arch Linux – Target Audience
●
People wanting to learn about Linux
●
Advanced users
●
Developers

6. Arch Linux - Background
●
Started in 2001 by Judd Vinet
●
Inspired by Slackware, Polish Linux
Distribution and CRUX

7. Arch Linux – History: stats
Random Arch Website Stats
1200 20000
Forum Posts (Right Y-axis)
Forum Users Registered
Flyspray Bugs Opened
18000
Flyspray Bugs Closed
Flyspray Users Registered
1000 Wiki Page Revisions (Right Y-axis)
16000
14000
800
12000
600 10000
8000
400
6000
4000
200
2000
0 0

8. Arch Linux – History: descendants

9. Arch Linux – Current Status
●
~3000 Official Packages
●
~3000 Semi-Official Packages
●
~40000 Unsupported PKGBUILDs
●
One kernel
●
i686 and x86_64 architectures
●
Proprietary software available
●
All major desktop environment, etc.

10. Packaging - Repositories
[core]
●
needed for building, booting and installing
●
~200 packages
●
updates must go through the [testing]
repository
[extra]
●
commonly used packages (>5% of users)
[community]
●
less commonly used packages (>1% of
users)

11. Arch Linux Package Manager
●
Uses the “pacman” package manager
●
Combines a simple binary package format
with easy to use build system
●
Fast! - according to Linux Format it beats
the competition by a wide margin
●
Does everything you expect from a package
manager (update system, resolve
dependencies, ...)

12. Package Creation
●
Very simple scripts required to create a
package
●
If you can build the software manually, then
you can create a package for it
●
Tool provided to build packages called
“makepkg”
●
Build script is placed in a file called a
PKGBUILD

13. Package Creation
●
Start with how you would normally install a
program:
$ tar -xf <pkgname>-<pkgver>
$ cd <pkgname>-<pkgver>
$ ./configure
$ make
$ sudo make install

14. Package Creation
●
Separate out the parts run as a user and
root into separate functions:
$ tar -xf <pkgname>-<pkgver>
$ cd <pkgname>-<pkgver>
build() {
./configure
make
}
package() {
make install
}

15. Package Creation
●
makepkg will automatically handle source
extraction into “$srcdir”
build() {
cd $srcdir/<pkgname>-<pkgver>
./configure
make
}
package() {
cd $srcdir/<pkgname>-<pkgver>
make install
}

16. Package Creation
●
Files need to be installed in “$pkgdir”,
which is compressed to make the package:
build() {
cd $srcdir-<pkgname>-<pkgver>
./configure –prefix=/usr
make
}
package() {
cd $srcdir-<pkgname>-<pkgver>
make DESTDIR=$pkgdir install
}

17. Package Creation
●
Add some information about the package at
the top of the file:
pkgname=foo
pkgver=3.0
pkgrel=1
pkgdesc="Example software"
arch=('i686' 'x86_64')
url="http://foo.example.com"
license=('GPL')
depends=('glibc')
source=(http://$pkgname-$pkgver.tar.gz)
md5sums=('d41d8cd98f00b204e9800f8427e')

18. Package Creation
●
makepkg automates many common
packaging tasks:
●
Stripping debugging symbols from
binaries
●
Compressing man and info pages
●
Setting compiler/linker options
(CFLAGS, LDFLAGS, MAKEFLAGS)
●
Removing common unwanted files
(libtool, infodir, …)

19. Package Creation
●
Two files are placed in the $pkgdir directory
with all package meta data
●
Then a (compressed) tar archive of the
$pkgdir directory is created
●
DONE!

20. Package Creation - Example
●
See terminal ->

21. Community - Developers
●
1 Project Leader
●
Deals with legal matters (exclusively)
●
33 Developers / Junior Developers
●
Runs infrastructure
●
Packages the packages in the official [core]
and [extra] repositories

22. Community – Developers
●
No formal rules of governance
●
Consensus-based decision making
●
Developers may in principle do whatever
they want, as long as they inform the other
developers of their intentions beforehand
and there is no serious, technical oposition
●
New developers added by invitation only

23. Community – Trusted Users
●
37 Trusted Users (Tus)
●
Disjont form the Developers
●
Runs the Arch User Repository (AUR)
●
Packages the semi-official packages in the
[community] repository
●
Ran as a democracy, governed by formal by-
laws
●
New TUs may apply to join

24. Community – AUR
●
Repository of PKGBUILDs
●
Anyone may sign-up and upload PKGBUILDs
●
Absolutely no quality-control of the
resulting packages, but some style
guidelines on the PKGBUILDs themselves
●
Popular, high-quality PKGBUILDS are often
picked up by TU's and added to the
[community] repository

25. Community – others...
●
Forum, wiki, bug tracker, mailing-lists, irc
channels are ran by separate teams
●
Disjoint from each other (and the
developers)

26. Getting involved
●
Actively contribute to the community
●
Provide PKGBUILDs for unpackaged
software
●
Help on the bug tracker
●
Contributing code to our projects
●
Update the wiki
●
Apply to become a Trusted User
●
Sponsoring and voting process...
●
Be invited onto the Developer team

27. Evolution of an example package
systemd: a Linux init system

28. Example - systemd
●
First packages for systemd were placed in
AUR in 2010
●
Lots of work was required to make it work
with Arch
“I'm highly dubious that Arch's kernel
will ever natively support systemd, but
I'm willing to give that a try as well
once 2.6.36 hits.”

29. Example - systemd
Over the next two years...
●
Unified the legacy Arch init system and
systemd
●
systemd moved from the AUR to
[community]
●
The systemd packager was invited to join
the dev team and moved systemd to [extra]
●
systemd moved to [core]
●
The legacy init system was deprecated and
systemd is now our only supported init
system

30. Why does it work at all?
●
Software developers write code that is
supposed to work...
●
Only suport the most recent version of our
packages
●
Don't support more options than strictly
necessary at the lower levels
●
Accept occasional user intervention

31. Vanilla Packages
●
Means packaging the software as the
upstream developers intended
●
Minimise patching – preferably only to fix
build issues
●
Result in any bug we find is (probably) not
distribution specific
●
Allows us to work more closely with
software developers to fix bugs

32. Working With Software Developers
●
All bug fix patches in Arch must be approved
by the upstream developers
●
That means that the Arch developers and
community have become regular code
contributors
●
Many Arch developers also have commit
access to upstream projects

33. Future Directions for Arch Linux
●
Majority response...
“Keep updating packages”
●
Add more focus on a particular areas
●
Add more architectures
●
Simplify the system further

34. Keeping Packages Updated
●
One of Arch Linux's greatest contributions
to the Linux community
●
Arch gets packages in their stable
repositories before some major distributions
get it in their developmental versions
●
The Arch community will identify bugs early
and report the issue to the software
developers
●
Fixes benefit all Linux distributions

35. Add More Architectures
●
Currently we support x86 in 32bit (i686) and
64bit (x86-64) varieties
●
There are community projects supporting
other architectures
●
ARM (v5, v6, v7)
●
PPC
●
...
●
Would be good to provide a way for these
ports to become official (like x86-64 did)

36. Arch Linux ARM
●
Non-official spin-off for the ARM
architecture
●
One of the distros recommended for the
Raspberry Pi

37. Simplifying the Filesystem
●
Usual filesystem layout has a lot of
redundancies
/boot
/bin
/etc
/home
/lib
/sbin
/usr
/bin
/lib
/sbin

38. Simplifying the Filesystem
●
Libraries
/boot
/bin
/etc
/home
/lib (essential libraries)
/sbin
/usr
/bin
/lib (rest of libraries)
/sbin

39. Simplifying the Filesystem
●
Keep all libraries in one place
/boot
/bin
/etc
/home
/lib -> /usr/lib
/sbin
/usr
/bin
/lib
/sbin

40. Simplifying the Filesystem
●
Executables – distinction between
directories is vague...
/boot
/bin (essential user commands)
/etc
/home
/lib -> /usr/lib
/sbin (system commands)
/usr
/bin (most commands)
/lib
/sbin (non-essential system)

41. Simplifying the Filesystem
●
Keep all libraries in one place
/boot
/bin -> /usr/bin
/etc
/home
/lib -> /usr/lib
/sbin -> /usr/bin
/usr
/bin
/lib
/sbin -> bin

42. Simplifying the Filesystem
●
/etc directory holds all configuration files
●
Beginning to have these placed in
/usr/lib/<pkgname> with files in /etc
overriding the default settings
●
Would be very helpful for a rolling release
system
●
Requires substantial work with upstream
projects to achieve...

43. Automating More Packaging
●
Task like rebuilds for library soname
changes are typically trivial
●
Would save a lot of time if we could
automate (most of) this
●
Most packages do not require architecture
specific changes – build for one and
automate the rest
●
Would allow us to focus more on improving
other areas of the distribution