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


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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

  1. 1. a simple, rolling-release distributionTom Gundersenteg@jklm.no
  2. 2. Overview● Arch Linux● Packaging● The community● Future plans
  3. 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. 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. 5. Arch Linux – Target Audience● People wanting to learn about Linux● Advanced users● Developers
  6. 6. Arch Linux - Background● Started in 2001 by Judd Vinet● Inspired by Slackware, Polish Linux Distribution and CRUX
  7. 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. 8. Arch Linux – History: descendants
  9. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 20. Package Creation - Example● See terminal ->
  21. 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. 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. 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. 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. 25. Community – others...● Forum, wiki, bug tracker, mailing-lists, irc channels are ran by separate teams● Disjoint from each other (and the developers)
  26. 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. 27. Evolution of an example packagesystemd: a Linux init system
  28. 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. 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. 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. 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. 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. 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. 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. 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. 36. Arch Linux ARM● Non-official spin-off for the ARM architecture● One of the distros recommended for the Raspberry Pi
  37. 37. Simplifying the Filesystem● Usual filesystem layout has a lot of redundancies /boot /bin /etc /home /lib /sbin /usr /bin /lib /sbin
  38. 38. Simplifying the Filesystem● Libraries /boot /bin /etc /home /lib (essential libraries) /sbin /usr /bin /lib (rest of libraries) /sbin
  39. 39. Simplifying the Filesystem● Keep all libraries in one place /boot /bin /etc /home /lib -> /usr/lib /sbin /usr /bin /lib /sbin
  40. 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. 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. 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. 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