And the AUR is largely possible because of pacman. Debian and RPM packages are very complex, and take a lot of effort to build, so even if there was a large collection of package source files available, downloading and building them is not an especially efficient solution for getting fresh software.
Whereas pacman packages are simple enough that an arbitrary package can be built using a single (admittedly quite large) shell script from another single source file.
How is it difficult to build a Debian package? I often make quick'n'dirty debian packages by hand.
In a directory (let's say /tmp/PKG) put all your files in the proper tree (/tmp/PKG/usr/local/bin, etc); then create a DEBIAN folder (/tmp/PKG/DEBIAN) with a control file in it. The control file structure is quite straightforward.
You can add preinst, postinst, prerm and postrm scripts as needed (in whatever language you fancy, sh, perl, etc) too. And that's about it, dpkg -b /tmp/PKG mypackage.deb.
Try backporting a package that depends on packages whose versions are older in the target release. It is a real nightmare and the packages themselves already exist. This is the most common use case I encounter that it much better handled by Arch.
AFAIK, The next version of pacman will support package signing. I suppose signed packages should begin to appear in the repositories as soon as pacman 4.0 is out.
Small correction, rpm can be complex, but a basic package is really easy. A few lines of package.spec file an a tarball of the package source. rpmbuild or mock handle all the grunt work of building the actual package and making a repo is as simple as running createrepo.
How robust is Arch? I am tempted to move from Ubuntu for the packaging system but I had bad experiences with Gentoo several years ago which makes me place a high value on keeping a working system without much maintenance or troubleshooting.
The core (i.e., non-AUR stuff) is pretty tock-solid. I switched from Gentoo to Arch a while ago, and the ease with which Arch can be managed is phenomenal.
I want an OS that:
* works
* stays the way I left it
* won't do things behind my back
* has a lot of packages for stuff that don't need to be built from source
Arch qualifies, Ubuntu doesn't qualify, Gentoo doesn't, Windows doesn't, and Mac OS X doesn't. If you're a user like me, Arch is for you.
Arch became stable. The package manager Pacman is mature. The advantage with Arch it's that you don't have to compile every packages from the sources, as Gentoo does, so it's faster, and easier to maintain. Arch absolutely worth a try. Only package from AUR needed to be compile, but it's for more specific package. For example, kernel, xorg, Gnome and so on are available with pacman as binary.
The question is not whether the package manager itself is stable but what degree of quality assurance is present in the packages themselves and in interdependencies between packages. I was always afraid to run "emerge world" because of how often it would break my system.
AUR is part of the problem that Debian Linux seeks to solve. AUR gets you 32,000 packages with uncertain quality and provenance. It's about two steps from downloading a zip file of binaries off the internet.
Debian has 29,000 packages that conform to a set of policies, with careful change control and vetted, active maintainers for each one.
The two methods are certainly not mutually exclusive, and reflect the differing needs of the user bases. We could just as easily say Debian is part of the problem that AUR seeks to solve, but "problem" is a bit of a loaded word.
I ran Debian for years and respect it. The reason I switched to Arch Linux is the complexity of the Debian system coupled with the assumption made by most Debian writers and maintainers that learning great gobs of stuff about Debian is a good use of my time.
What would be ideal is a distro that combines Arch Linux's ethic of keeping small the amount of stuff a guy has to learn to make a change to the system with Debian's loving craftsmanship.
I still have fond memories of how much saner the default configuration of Lynx was on Debian Potato and Woody than on other distros (including Arch Linux) and how well integrated Lynx was with the rest of the system.
I hope you do not interpret this as a troll but what did you find too confusing about debian? I have been a debian user for 14ish years now so my viewpoint is a little biased.
As far as "learning about debian" goes what distro specific stuff did you have to learn that you have not needed to bother with in Arch? Whenever I have flirted with other distros there is always a little learning curve at first; gentoo/emerge, *bsd/ports, redhat/rpm, etc.
There might be an inaccuracy in my recollection because I have not been using Debian since 2006.
The shell scripts that run when the OS boots (in /etc/init.d/ and /etc/rc* IIRC) are a lot more numerous on Debian than on Arch -- or so I seem to recall. So for example I remember that trying to increase my boot speed by identifying and disabling unneeded services was an exercise in frustration. I configured my Arch Linux to boot to the text-mode console, and if I wanted to start X and Gnome, I used startx. I probably never tried to do the same thing in Debian, but am left with the distinct impression that it would have been harder. (Why would I want to do that? As a procrastination-reduction measure: when I wanted to focus on work, I would quit Gnome and X. On my slow machine, it would take a good 30 seconds or more for Gnome to restart, and the thing about procrastination -- at least for me -- is that if I can arrange it so that the decision to procrastinate is not immediately rewarding, then the temptation to procrastinate becomes weaker. I realize most people do not need their Linux install to help them fight procrastination, but this is an example of my tailoring my install to my particular needs, so I think it is relevant to whether Debian or Arch is easier to customize.)
When you build something from source on Arch, it takes very little additional effort to arrange it so that Pacman can install it and the arch build system can rebuild it from source. And if you make the effort, it becomes easy at a later date to look up what you did to get the software to compile, so the (again, mild) additional effort ends up saving you time in the long run when you need to rebuild stuff you built years ago. And since pacman installed every file in my /usr and my /bin, if I ever needed to know where a file in /usr or /bin came from, pacman was able to tell me even if I had compiled the software from source. I know that all this is doable on Debian, but doing it on Arch is very very easy. So I liked building stuff from source on Arch better.
I personally don't but I know a high-profile web-developper who does.
Now, how often do you guys actually perform upgrades on a production box (security aside)?
I go by this rule: If it ain't broke, don't fix it.
It should be noted that a lot of the important stuff is now off-loaded to language-specific package management. Python libraries are a good example with virtualenv and your-sensible-python-package-installer, the actual distro repository doesn't matter that much anymore.
Personal. I love Arch, but lack of a separate channel for security updates pushes me toward other production systems. (Not saying it can't be done--don't want to start that argument.)
How are things going regarding signing of packages to prevent man-in-the-middle attacks? Looking forward to give arch a closer try, but this is still a big showstopper because I would like to sync while I'm on e.g. an open airport network without the man-in-the-middle security hole.
The package name (nodejs-git 20110613-1) confused me. I assumed it was a snapshot from 2011-06-13, but after looking at the PKGBUILD file I see that it is cloning the github repo. My mistake.
fwiw, aur packages with the -(cvs|hg|git|svn) suffix usually track the development, while the date actually refers to when the build was last updated. Installing the package will actually give you today's date as the version tag. I can see why the confusion happens, though :)
Hm, as a general rule, I'd actually suggest continuing to avoid such packages in general, unless you know that they're what you need: you need to track whether there's been a source code update, whether someone broke the upstream build, whether your current versions of other packages depend on it
(example: x264-git, pretty much requires that you also install libav-git/mplayer-git, and then of course blender doesn't work, and so on. It can become quite messy at times.)
It's worked pretty well for the last three years. Arch Linux will never reach the same scale that Ubuntu or Debian will simply because of its barrier to entry, so I imagine it should work fine for the immediate future.
Whereas pacman packages are simple enough that an arbitrary package can be built using a single (admittedly quite large) shell script from another single source file.