Arch Linux Team

One of the most notable characteristics of Arch is its rolling release model, which assures users that they will always have the latest and newest version of a program available. Has this model brought any noticeable disadvantages (for example: programs that depend on older libraries who aren’t on the system anymore because of an update)?

Thomas Bächler:
There are two huge disadvantages:

  1. Library updates break ABI and API compatibility. In the former case, we have
    to do mass rebuilds in our testing repositories so everything is compatible
    again in the end. In the latter case, the same is necessary, but we also have to
    find or write patches for many applications. This is not a big problem, but has
    to be done right.
  2. Hardware incompatibility: There are 2 candidates that keep breaking people’s
    computers: Linux and Xorg. As a current example, many ATI cards are barely
    usable on Arch right now – that will hopefully improve with the release of
    2.6.32, but I am sure something else will break.

Allan McRae:
Rebuilds for library, so namebumps are the biggest issue, but the rebuild process
for Arch is quite streamlined. Because we try to have the latest versions of
packages, we often run into issues that have not been encountered before, which
requires working with upstream to find and patch the problem code.

Aaron Griffin:
The biggest problem with the rolling release model is laziness – from upstream
developers and Arch users. We try to stay up to date wherever possible, but some
upstream developers are slow at adopting new changes. This means we need to do
extra work to make their software compatible with new library versions and
things of that nature. On the user end, you get people who don’t regularly
update their system (something we indicate as very important), and you end up
with newer software and older libraries on the same system, causing breakages.

Giovanni Scafora:
Arch Linux is a rolling release. That’s good, and I noticed no disadvantage.

Ionut Biru:
Let’s clarify something first. We have the latest and newest stable version of
a program.

Having that from time to time, we have to rebuild a lot of applications and
sometimes we have to patch and collaborate with upstream developers. Because we
are early adopters of all, new users have to suffer sometimes. xorg and drivers
rewrite is one example.

Tobias Kieslich:
It’s a two-side sword. It sure is a pain in the neck to recompile half of the
distro for an ABI incompatible ssl update. On the other hand, it reveals bugs
and keeps the packages up to date. For what Arch is and for what most people use
it, I think the rolling release is surely benficial.

Ronald van Haren:
It requires a lot of rebuilding for some particular updates and sometimes a not-so-widely used package is missed, but I think we are on average very quick in
fixing these things. As we require signoffs from other developers before we
move important stuff to core, it is highly unlikely that this happens to one of
the system’s core packages.

Pierre Schmitz:
The most notable disadvantage of running the latest software is seeing bugs and
problems no one else has discovered before. But fortunately new versions of
software generally fix more bugs than they introduce.

But serious regressions are really rare as we test important packages before
they are moved to our [core] repository.

But as an Arch user, one should be able to debug simple problems and shouldn’t
be scared of the command line.

Dan McGee:
We encounter quite a few first adopter hurdles when rebuilding packages. This
is especially true when building a core library that involves rebuilds of
several packages that often require some patching to be compatible with a newer
version of the library.

Arch uses the PKGBUILD system to make and compile packages. What does the future hold in store for the PKGBUILD system? Are there any new features or modifications that are planned?

Dieter Plaetinck:
Do we need any?

Allan McRae:
Yes. Improved support for running test suites. Splitting debug symbols into
separate packages. The way VCS packages are handled needs an overhaul.

Aaron Griffin:
I’ll defer to Allan here. Suffice to say that things are always in flux and
always improving. That’s the way we do things. Short answer: Yes. 🙂

Ionut Biru:
The overall format of PKGBUILD is good as it is now, but improvements are always

Tobias Kieslich:
I think that we can roll separate packages from a single build now is a big
plus. It allows for smaller packages, lesser dependencies.

Arch Linux has steadily grown in user-base while still holding true to the simple DIY design. Without holding people’s hands, Arch is growing and growing. What do you attribute this to?

Thomas Bächler:
Arch works. It’s that simple. One reason is its simple design, the other is that
its users are required to know and understand their system – and we make it easy
for everyone to understand it.

The Arch Linux community is very strong and friendly and communicates a lot. We
have a very active BBS and probably the most active IRC channel I have ever
seen. And this community isn’t just a bunch of dumb idiots, but our average
community member is smart and knows his/her way around Linux and Arch.

Another reason might be that our users want to get their share when we finally
succeed in our evil and secret world domination plans.

Allan McRae:
The developers being awesome.

Aaron Griffin:
I think that people are getting tired of Linux distros trying to be more
Windows-like. People see all this automation with 100 links in the chain, only
to see one link fail and bring the whole thing crashing down around them. With
Arch, they gain awareness of the whole chain, not just the tail end that they

Ionut Biru:
I think because we have a rolling release model, because we have the latest
stable version of application and because it is simple to use. The community has a
big role because it is friendly and helpful with all new comers.

Tobias Kieslich:
A nice and helpful community. I think people take pride in explaining things
and not throwing a RTFM on new user just because they can. On the other end of
that, stick people become more curious about the abilities of Linux and are
willing to try and learn.

Pierre Schmitz:
At first, I am quite sure that Arch’s growth is limited. Most people don’t care
what goes on behind the scene of their operating system or even want to control
every single bit of it. And don’t get me wrong, that is perfectly fine.

One of our strengths is that, while evolving on all levels, we still try hard to
keep it simple. This makes it easy for new users to build their own packages
and understand the way how are things done in Arch.

Hugo Doria:
We look sexy.

What does the future of pacman hold? Where is development currently going?

Allan McRae:

Dan McGee:
Signed packages are super important and are targeted for the next major pacman
release. Besides that, alternative compression methods, deltas, and an improved
database interface are large features that may find their way into the code in
the next year.


  1. 2010-01-11 4:53 pm
    • 2010-01-11 5:17 pm
    • 2010-01-11 5:26 pm
    • 2010-01-11 5:28 pm
    • 2010-01-11 6:34 pm
    • 2010-01-11 7:24 pm
    • 2010-01-12 12:38 am
    • 2010-01-12 3:29 pm
      • 2010-01-12 5:49 pm
        • 2010-01-12 8:40 pm
          • 2010-01-12 10:06 pm
    • 2010-01-12 5:58 pm
    • 2010-01-12 8:33 pm
  2. 2010-01-11 5:15 pm
  3. 2010-01-11 6:09 pm
    • 2010-01-11 6:29 pm
    • 2010-01-11 6:29 pm
    • 2010-01-11 7:29 pm
  4. 2010-01-11 6:23 pm
    • 2010-01-12 5:46 am
    • 2010-01-12 11:13 am
    • 2010-01-12 5:13 pm
      • 2010-01-12 9:18 pm
        • 2010-01-13 4:34 am
          • 2010-01-13 8:26 am
        • 2010-01-13 4:26 pm
  5. 2010-01-11 6:52 pm
    • 2010-01-11 10:44 pm
      • 2010-01-12 5:36 am
        • 2010-01-12 6:02 am
        • 2010-01-12 3:34 pm
  6. 2010-01-11 8:22 pm
  7. 2010-01-12 6:04 am
    • 2010-01-12 12:56 pm
      • 2010-01-12 3:23 pm
        • 2010-01-12 3:46 pm
    • 2010-01-12 1:44 pm
      • 2010-01-12 3:51 pm
        • 2010-01-12 4:45 pm
          • 2010-01-12 7:56 pm
          • 2010-01-12 8:45 pm
          • 2010-01-12 9:07 pm
          • 2010-01-13 4:27 am
        • 2010-01-12 5:15 pm
          • 2010-01-12 6:57 pm
          • 2010-01-12 8:40 pm
          • 2010-01-13 1:04 am
          • 2010-01-13 7:54 am
    • 2010-01-12 5:55 pm
      • 2010-01-13 4:21 am
  8. 2010-01-12 5:30 pm
  9. 2010-01-12 6:22 pm
  10. 2010-01-13 4:09 am
    • 2010-01-13 4:44 pm
  11. 2010-01-13 12:21 pm
  12. 2010-01-13 1:17 pm
  13. 2010-01-14 1:04 am
    • 2010-01-14 11:49 am
      • 2010-01-14 4:16 pm
        • 2010-01-14 6:42 pm
  14. 2010-01-15 7:14 am