Your SlideShare is downloading. ×
Distro Recipes 2013 : Introduction to Arch Linux: a simple, rolling-release distribution
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Distro Recipes 2013 : Introduction to Arch Linux: a simple, rolling-release distribution


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. a simple, rolling-release distributionTom
  • 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)● Dont 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 Stats1200 20000 Forum Posts (Right Y-axis) Forum Users Registered Flyspray Bugs Opened 18000 Flyspray Bugs Closed Flyspray Users Registered1000 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="" 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 TUs 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 packagesystemd: 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 “Im highly dubious that Archs kernel will ever natively support systemd, but Im 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● Dont 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 Linuxs 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