
Why AUR is part of the Arch Linux Success - Nic0
http://www.nicosphere.net/why-aur-is-part-of-the-arch-linux-success-2529/
======
LeafStorm
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.

~~~
ch0wn
This is a very important point. The learning curve for building Arch packages
with pacman is ridiculously low compared with RPM or Debian packages.

My biggest grief back when I used Arch was the missing support for signed
packages. Has there been any work in that direction in the meantime?

~~~
wazoox
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.

~~~
foomanchu
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.

------
foomanchu
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.

~~~
bitwize
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.

~~~
Nick_C
For those reading this to pick up info, Slackware qualifies for all four
points (depending on how big you mean for a lot), as does any of the BSDs.

------
hapless
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.

~~~
hollerith
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.

~~~
dfc
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.

~~~
hollerith
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.

------
alexis-d
It's more than a part, it's a huge part. It's really easy to use, and you can
find everything in it!

------
Palomides
semi-related question to the arch users: are you running arch on production
systems, or personal systems (or both)?

~~~
nakkiel
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.

------
gorm
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.

------
dfc
I'm a debian user so I do not know a lot about PPA but I'm atleast aware of
ubuntu' ppa. What's the difference? (Other than signed packages;)

------
parshap
> For example, if I try Node.js, I do not want the version of last year, but
> the latest.

[http://aur.archlinux.org/packages.php?O=0&K=nodejs&d...](http://aur.archlinux.org/packages.php?O=0&K=nodejs&do_Search=Go)

That is not a very impressive list.

~~~
adestefan
I'm not a node person, but isn't that exactly what you want? There's node and
npm. You install those two and then get everything else via npm.

~~~
parshap
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.

~~~
copper
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 :)

~~~
mcrittenden
As a new Arch user, this is really useful info. I too was confused by this and
I've been avoiding packages with names like these.

~~~
copper
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.)

------
gtaylor
Definitely love some AUR!

------
xxiao
packaging is the easy part, how do they maintain all the dependencies among
packages? will that be scalable? otherwise it will be a mess quickly.

~~~
freyrs3
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.

~~~
nakkiel
> "barrier to entry"

Seriously? Arch is KISS. There's no magic involved so I don't see how it's
more difficult to use it than Debian.

