pacaur - an AUR helper that minimizes user interaction

Spyhawk · 2011-05-21 17:36:16

[2017-12-15] This project is now unmaintained. Users are encouraged to move to another solution (see wiki for alternatives).

----

Hi there,

For quite some times, my favourite AUR helper has been pbfetch but I've been impressed by the simple and ultra fast cower that seems to outperform everything else.

Consequently, I've written pacaur, an AUR helper that uses cower as backend. This is basically a complete rewrite of pbfetch using cower as much as possible, expac and sudo. It has been written purely for my own use but it possibly might interest some people of the community.

Pacaur main feature revolves around a "fast workflow" idea, that is, spending as less time as possible interacting with package management prompts. The objectives of speed, simplicity and uncluttered interface were also taken into consideration. Do not expect any new breaking revolutionary features, pacaur only intends to reuse the best tools and ideas out there :]

Pacaur is targeted at advanced users who want some degree of automation for repetitive tasks. As such, the user is expected to be familiar with the manual build process, and being knowledgeable about pacman, makepkg, sudo and gpg configuration options. It provides two sets of command line options, for those that prefer to keep their AUR frontend separate from Pacman, and those who prefer to have a single tool to manage AUR and official repositories (see man page).

All credits go to dalingrin (pbfetch concept), falconindy (cower, expac), bruenig, keenerd and pbrisbin (small part of the code are taken or inspired from packer and aurget), as well as the numerous others contributors (translators, shell completion files contributors, testers that gave feedback, bug reporters, main coder's motivators, etc.).

Note: The words "an AUR helper that uses cower as backend" are less true than before, since nowadays pacaur relies on cower only for its info and search features.

Packages || pacaur (stable) | pacaur-git (development)
Links || Wiki page | GitHub repository | Changelog | Known bugs | Internationalization | Bug reports instructions

============================

UPDATE July 2015: Why pacaur sucks less

So we're now in year 2015, and pacaur has become quite popular in the last few months. I quite frankly didn't expect it to be so well received by the community when I initially released it, but here we are, four years and quite a few releases later.

I often see people discussing which AUR helper they use and why they like it, and while some people can succinctly describe what pacaur does better or differently than other popular helpers, I rarely see someone that truly understands what pacaur does better than most of them, or rather, why pacaur sucks less. Here is an attempt to give a better understanding of what makes it different from other "complete" helpers.

To put things into perspective, I've myself used a wide range of AUR helpers the past 10 years, starting from yaourt back in the days when it was basically the only choice, jumped then to the faster Clyde, moved on to packer when an annoying bug wasn't fixed by the dev and that I couldn't fix it myself (Clyde passed away a little after, RIP Clyde), tried various alternatives including aurget, cower and pbfetch, which I liked the best overall. Pacaur has obviously been influenced by all of the helpers I've used, integrating the features I liked while keeping the others away.

Let's start with the reasons you would not want to use pacaur in the first place:

PACAUR ISN'T FOR YOU IF...

You are a newbie. Pacaur is targeted at advanced users only. Lazy, competent users that want some degree of automation for repetitive tasks. Pacaur is designed upon your assumed knowledge of makepkg and its configuration options, the AUR as well as pacman, cower, sudo, and gpg configuration options. If you want to make full use of pacaur, you have to master these tools first and be ready to deal with the expected unexpected breakage. Again, if you're a newbie, pacaur is NOT for you.

You want a full featured helper that holds your hand. Pacaur is merely designed as a tool that simply extends pacman to manage the AUR without many extra features. Users are still supposed to take responsibility of the system packages maintenance manually, such as merging .pacnew or dealing with unnecessary dependencies.

You don't want to use sudo. Pacaur makes heavy use of sudo. If you can't or don't want to install sudo on your system, pacaur is not for you.

You want interactive search, integrated comments viewing, votes capability or packages statistics. These features are considered by myself not useful, most of the time useless, completely stupid or bloat (respectively, or all of them together). Also, these features are out of scope of the "simple pacman extension" design of pacaur and there are individual tools that simply do a better job.

You want --skipchecksums or customizepkg. By design, pacaur doesn't allow to bypass "issues" that should be fixed upstream in the AUR or in the installed software. Each user should participate to the improvement of the PKGBUILDs by reporting issues to their respective maintainer, instead of selfishly avoiding the issue just for themselves. If you need some manual tinkering, you can simply use cower and the manual way, or you can share and maintain your own modified PKGBUILD in the AUR.

You already have your own helper that fits your workflow. Pacaur has been solely designed to fit my own workflow, and similarly some of you might already have coded a tool for yourselves. Don't change it, you already have the best tool available for you.

PACAUR MIGHT BE FOR YOU IF...

... you've made it this far and don't absolutely require any of the above.

Here are a few pacaur characteristics that you might find interesting:

It minimizes user prompt interaction. Pacaur retrieves and edits all PKGBUILDs, solves all conflicts and asks about providers before building anything, before compiling and installing all packages without user interaction. This is the most well known feature, and the main reason people use it. Signature checking is also done for all packages before building anything.

It correctly supports split packages. Split packages are packages that are build from a single PKGBUILD and are officially supported since AUR 3.0.0 was put online in May 2014. Adding full split packages support with proper independent subpackages installation was quite difficult and required the internal logic to be completely rewritten to make pacaur behave as expected. Conversely, split packages support in yaourt or packer is implemented merely as a hack, and as a result these tools are quite buggy. They will likely never support split packages correctly unless their internal logic is rewritten.

It computes the dependency tree before doing anything. By using the full secured RPC interface to solve the dependencies, all required packages can be found even before any PKGBUILD is downloaded on the system. This allows to check the dependency tree and avoids a dependency build failing due to a faulty PKGBUILD when other packages have already been built and/or installed.

It has a secure and accurate solver. Getting dependencies in a secure and accurate manner from PKGBUILDs has historically been very difficult, especially on the AUR interface. To make it short, this issue has been solved by developing .SRCINFO files (implemented in AUR 3.0.0 and pacman/makepkg 4.2) to provide complete and accurate information in the AUR RPC interface. Using the information from the RPC avoids to parse PKGBUILDs entirely, making the process in AUR helper both accurate and secure (and also faster). Most other helpers solve the dependency tree by parsing the PKGBUILDs directly, either at a cost of security (when parsed by bash itself, like packer does by default) or at a cost of inaccuracy (when done with another language, like aura does).

It provides two sets of command line options. As such, pacaur can be used by users who prefer to have a single tool to manage officials and AUR repositories, or by users who prefer to keep their AUR frontend separated from pacman.

It has a powerful search with regex support. Granted, this is not specific to pacaur since this feature is directly provided by cower, whose search capabilities are second to none. Even though you don't use/don't like pacaur, having cower available on your system is a must for any advanced Arch users.

It takes existing options into account.. Pacaur uses colors and extends pacman verbose interface to the AUR if these options are enabled. The makepkg environment variables are also fully honored, making it easy to chain pacaur with other tools such as pacmatic or powerpill. Some other helpers simply duplicates these settings (like yaourt, mostly for historical reasons).

It is simple and fast. Pacaur does not add a lot of features, but simply extends pacman to manage the AUR. Staying away from extra features helps in having basic functionalities working (more or less ;]) without bugs. It is a small bash script using existing tiny libraries with very good performance and a small memory footprint, and is based on the libalpm C interface directly maintained by a pacman developer, ensuring it is correctly updated when needed.

It rebuilds packages only if needed. Pacaur checks built packages in the cache, and rebuild them only if needed. Also, the --devel flag will reorder the dependencies in the correct order, instead of simply adding them to the build list.

It is documented. Pacaur has a man page and a wiki page with lot of additional information. Read them.

Note: This text is obviously not complete, potentially inaccurate and will be updated as needed.

TL;DR: Because it sucks less.

Last edited by Spyhawk (2017-12-21 18:47:45)

JerichoKru · 2011-05-22 00:19:04

Interesting project, I'm installing it now and will give it a try.

Ape · 2011-05-28 12:50:42

Did you notice this typo in the --help output?

-e, --edit edit target PKBUILD -- can be combined with the -d, -b, -m, -y, -u, -abs flags

Anyway, this is looking very nice. Finally a reason to stop using my slurpy wrappers.

Spyhawk · 2011-05-28 13:54:54

Ape> Thanks! I'll correct this typo in the upcoming 0.9.9 release. Great to see that this script is useful to other people too

Also, I'll revert the changes I introduced in the last release (0.9.8). The available version of outdated packages (pacaur -Qu) isn't properly displayed when using the testing repo. This is because the code return both new version number (core/extra repo, AND testing) while pacaur waits for one single value to be returned. Unfortunately, this seems not trivial to fix without losing lot of speed. I'll fix this issue in a different branch before merging it later.
(Edit: fixed in expac-git)

Last edited by Spyhawk (2011-06-23 07:57:23)

Spyhawk · 2011-06-23 07:56:24

Added --devel flag to upgrade all dev package (hopefully working with all kind of devel packages.. )

Last edited by Spyhawk (2011-06-23 10:42:00)

pogeymanz · 2011-07-04 14:12:22

I have a feature request. It is the main reason I use yaourt instead of any other AUR helpers.

Can pacaur cache AUR packages? Yaourt and previously bauerbill could cache AUR packages in the same directory as pacman's cache. This feature came in very handy for me when kernel-ck had some bug that gave me hard-locks. If I didn't have an old version cached, I would've been stuck with the stock Arch kernel.

Spyhawk · 2011-07-04 14:41:23

What do you mean by "cache AUR packages"?
Any package built is kept in the PKGDEST directory you've defined in /etc/makepkg.conf, regardless of the AUR helper you are using. Afaik, all AUR helper are built upon makepkg.

Last edited by Spyhawk (2011-07-04 14:42:06)

pogeymanz · 2011-07-04 18:32:12

Well, that is true. But the makepkg option only works if my user has write permission to /var/cache/pacman/pkg or if I run pacaur as root.

With yaourt, it does the build and then, using sudo, places the built package in /var/cache/pacman/pkg (optionally) without the makepkg.conf option.

Also, for some strange reason, if I try to build something with pacaur (or clyde) and I want to edit the pkgbuild, gvim opens and the build continues even if I just leave gvim open with unsaved changes. What could be causing that? Yaourt still works correctly: everything is paused until the gvim window is closed.

Spyhawk · 2011-07-04 21:19:13

pogeymanz wrote:

Well, that is true. But the makepkg option only works if my user has write permission to /var/cache/pacman/pkg or if I run pacaur as root.
With yaourt, it does the build and then, using sudo, places the built package in /var/cache/pacman/pkg (optionally) without the makepkg.conf option.

I'm not going to reimplement features that are already provided by tools upon which the script is based: this is clearly out of scope of the objectives and kiss design mentioned above, and the way to bloatedness (see yaourt).

If you really need to move your packages in that directory, change the right permission of the directory, or create a new group that allow you and root to write in that directory, or use an alias pacmanScc='sudo mv tmp_directory /pacman/pkg && pacman -Scc', send a patch to makepkg devs, etc.

Also, for some strange reason, if I try to build something with pacaur (or clyde) and I want to edit the pkgbuild, gvim opens and the build continues even if I just leave gvim open with unsaved changes. What could be causing that? Yaourt still works correctly: everything is paused until the gvim window is closed.

This issue seems specific to gvim, no problem to report with vim and nano. In /etc/pacaur.conf, try:

editor="gvim --nofork"

This seems to do the trick.

EDIT: As of 2.1.5, pacaur extends the -Sc and -Scc options to the PKGDEST directory if defined. You'll still have to adapt permission if you intend to use the main pacman pkg cache however.

Last edited by Spyhawk (2011-07-20 21:24:09)

pogeymanz · 2011-07-21 12:39:32

Thanks, Spyhawk. The --nofork option works and my life is now better.

As for the package export, I understand why you wouldn't add a feature that is (almost) redundant. Oh well.

I'm also curious as to why editing the PKGBUILD is not an option. It isn't annoying if I'm installing one AUR package, but if I want to install several, it becomes a pain to close all the editors. It seems like the workflow would be faster if it asked me to edit the file and I could type n+enter a few times.

It wouldn't hurt the speed for just one AUR package either. If you use vim, you have to type :q to close it, whereas if you didn't want to edit it at all, typing n+enter isn't any more work.

Also, I LOVE that all the editing happens BEFORE the packages get installed. Why in the world do all the other AUR helpers do it wrong?

SanskritFritz · 2011-07-21 13:02:56

pogeymanz wrote:

Also, I LOVE that all the editing happens BEFORE the packages get installed. Why in the world do all the other AUR helpers do it wrong?

Are you serious? Other aur helpers allow you to edit the PKGBUILD only after the package was installed? I severely doubt this.

pogeymanz · 2011-07-21 13:12:14

SanskritFritz wrote:

pogeymanz wrote:
Also, I LOVE that all the editing happens BEFORE the packages get installed. Why in the world do all the other AUR helpers do it wrong?
Are you serious? Other aur helpers allow you to edit the PKGBUILD only after the package was installed? I severely doubt this.

I should've worded that differently.

Most are helpers work like this:

AURHELPER -S package1 package2 package3

Edit PKGBUILD1?

Build Package1

Edit PKGBUILD2?

Build Package2

Edit PKGBUILD3?

Build Package3

Bauerbill did this:

Edit PKGBUILD1?
Edit PKGBUILD2?
Edit PKGBUILD3?

Build package1
Build package2
Build package3

which is what I was basically asking Spyhawk if he would do.

Spyhawk · 2011-07-21 13:16:26

pogeymanz wrote:

I'm also curious as to why editing the PKGBUILD is not an option. It isn't annoying if I'm installing one AUR package, but if I want to install several, it becomes a pain to close all the editors. It seems like the workflow would be faster if it asked me to edit the file and I could type n+enter a few times.
It wouldn't hurt the speed for just one AUR package either. If you use vim, you have to type :q to close it, whereas if you didn't want to edit it at all, typing n+enter isn't any more work.

If you use the non-pacman like operations, that's already possible (ie, "pacaur -y pkg" install without editing, while "pacaur -ye" edit and then install). When using pacman-like shorcuts you have to use --noedit. But you're totally right on the fact that it is not possible to edit pkgbuild selectively with pacman-like shortcuts. I've been wondering if I would implement it or not for quite some time now, and couldn't decide knowing that people would use the non-pacman like operation set anyway. I could try for the next release and see how it goes. Or maybe should I implement "-Se, -Swe, -Sue" shortcuts? No idea which one is better.

Edit: 2.1.9 includes selective editing.

pogeymanz wrote:

Also, I LOVE that all the editing happens BEFORE the packages get installed. Why in the world do all the other AUR helpers do it wrong?

You have to thanks falconindy. Not that it is impossible to implement in other aur helper, but using cower as backend makes it *very* easy. And honestly, pacaur isn't more than a slightly improved pbfetch using cower. All other people did the hard work before :]

Last edited by Spyhawk (2011-07-21 23:13:17)

pogeymanz · 2011-07-22 16:06:57

Spyhawk wrote:

If you use the non-pacman like operations, that's already possible (ie, "pacaur -y pkg" install without editing, while "pacaur -ye" edit and then install). When using pacman-like shorcuts you have to use --noedit. But you're totally right on the fact that it is not possible to edit pkgbuild selectively with pacman-like shortcuts. I've been wondering if I would implement it or not for quite some time now, and couldn't decide knowing that people would use the non-pacman like operation set anyway. I could try for the next release and see how it goes. Or maybe should I implement "-Se, -Swe, -Sue" shortcuts? No idea which one is better.
Edit: 2.1.9 includes selective editing.

Ah, beautiful. Pacaur is pretty much perfect for me now. I hadn't played around with the non-pacman-like options, but I like 2.1.9.

Spyhawk wrote:

You have to thanks falconindy. Not that it is impossible to implement in other aur helper, but using cower as backend makes it *very* easy. And honestly, pacaur isn't more than a slightly improved pbfetch using cower. All other people did the hard work before :]

Yes, falconindy is amazing. People like him and Xyne really make using Arch fun and exciting. Thanks both to you and him, then. ;-)

Spyhawk · 2011-07-29 12:16:49

Just a quick note about the 2.2.0 release:
- I simplified the conf file (removed the pacmanBin variable), please use the new config file.
- I removed --abs option. This one was very simplistic and there is better alternative out there (see absent for example).
- Although I started working on customizepkg support in a separate branch, it is not included as I consider customizepkg as being more an ugly hack than encouraging to do the "right" thing. I'm still looking for a valid use case where it is better to patch local pkgbuild again and again instead of fixing the upstream pkgbuild or adding a new pkgbuild to the aur. Full dependencies support requires quite lot of additional work anyway (I started it, but won't finish it without knowing why doing it).
- I removed the -b/--build option. It should have been useful when using a modified pkgbuild (see above), and was buggy anyway.

Let me know if you were actively using one of the removed "features" and I might work on it and readd later.

Other features:
- added -cc option to clean up the entire build directory (useful when the "clean" option is turned off in the conf file).
- added per user config file
- $tmpDir can now be used as $buildDir.
- -Qu option now show package group.

Also, pacaur has now reach a point when it can be considered as a serious alternative to other aur helpers. If you don't mind having two tiny C deps (cower+expac), then it is better than pbfetch and faster than packer (slighty faster when installing an AUR package, but significantly faster when installing many packages at the same time or upgrading). Anyway, I guess if you like pacaur, the main reason isn't the speed improvement :]

Last edited by Spyhawk (2011-07-29 12:52:58)

anonymous_user · 2011-07-30 06:43:31

When trying to update AUR packages, I get quite a lot of "Couldn't resolve host name" and "Timeout was reached" messages. Afaik the AUR is not currently down or anything, so what gives?

Secondly, this is the last output I get:

:: packer 20110715-1 -> 20110729-1
error: no targets specified (use -h for help)

However it doesn't actually proceed to upgrade packer.

Last edited by anonymous_user (2011-07-30 06:43:48)

Spyhawk · 2011-07-30 08:06:10

Thanks, someone already reported a similar error on the AUR page. I somehow nuked part of the upgrade function

As for the "Couldn't resolve host name" and "Timeout was reached" message, this happens when cower can't contact the AUR. Maybe a temporary problem with your connexion? Let me know if you keep receiving this message (you can try to list upgrade with cower and see if the problem happens with it, ie "cower -u"). Also, I'm out of town today, and probably won't have time to fix all the issues you reported guys

Edit: 2.2.1 released with numerous bugfixes. Although pacaur -u is broken in 2.2.0, you should still be able to upgrade with pacaur -Sua.

Last edited by Spyhawk (2011-07-30 18:28:30)

Berseker · 2011-07-31 16:10:35

OMG, i stopped following various projects progression and now I find

clyde --> stopped
bauerbill --> stopped

lucky me that I immediately found this project, seems a good one!
thanks

MoonSwan · 2011-08-02 03:22:09

Dear Spyhawk, Would love to use your app but I keep getting the same error over and over when I try to do "makepkg -sci PKBUILD:"

/home/heather/aur/pacaur/PKGBUILD: line 3: syntax error near unexpected token `newline'

I'd fix this (and i did try to fix it...) but I don't know how or what the error is about. Is it me or is the pkgbuild flawed? If it's me I'm gonna feel reaaally stupid but I'd rather that happen than bugs be in the build, it's safer that way.

Top 10 lines of the build script:

<?xml version="1.0" encoding="UTF-8"?>


<!-- DOCTYPE html -->
<html>
  <head>
    <meta charset='utf-8'>
    <meta http-equiv="X-UA-Compatible" content="chrome=1">
    <script type="text/javascript">var NREUMQ=[];NREUMQ.push(["mark","firstbyte",new Date().getTime()]);</script>
        <title>PKGBUILD at 57f4e956ba9705bfe5c197934a60444332f64742 from Spyhawk/pacaur - GitHub</title>
    <link rel="search" type="application/opensearchdescription+xml" href="/opensearch.xml" title="GitHub" />
    <link rel="fluid-icon" href="https://github.com/fluidicon.png" title="GitHub" />

Last edited by MoonSwan (2011-08-02 03:25:21)

anonymous_user · 2011-08-02 03:32:03

Somehow you messed up when downloading the PKGBUILD. It should look like:

# Maintainer: Remy Marquis <remy.marquis@gmail.com>

pkgname=pacaur
pkgver=2.2.1
pkgrel=1
pkgdesc="A fast workflow AUR wrapper using cower as backend"
arch=('any')
url="https://github.com/Spyhawk/pacaur"
license=('GPL')
depends=('cower' 'expac')
optdepends=('pacman-color: colorized output'
            'sudo: install and update packages as non-root')
backup=('etc/pacaur.conf')
source=($pkgname $pkgname.conf README.pod)
md5sums=('5e961af559a7a74b09647374365b947a'
         '291424f94262bc5105a34f06a3992012'
         '4baf408fc782faaf814110d31a2fc108')
build() {
  mkdir -p "$pkgdir/etc/"
  install -D -m644 ./$pkgname.conf $pkgdir/etc/$pkgname.conf || return 1
  install -D -m755 ./$pkgname $pkgdir/usr/bin/$pkgname || return 1
  mkdir -p "$pkgdir/usr/share/man/man8/"
  pod2man --section=8 --center="Pacaur Manual" --name="PACAUR" --release="$pkgname $pkgver" ./README.pod > pacaur.8
  install -m 644 ./pacaur.8 $pkgdir/usr/share/man/man8/pacaur.8 
}

However since the pacaur has several binary files, I recommend you download the entire tarball anyhow.

MoonSwan · 2011-08-02 05:30:54

Funny thing... i had downloaded the tarball on the first try to build this app; believe it or not. I'm not sure I believe it and I'm sitting here mystified.

Thank you Nee.

Berseker · 2011-08-03 07:56:34

has anyone tought yet to make a bash_completion file for pacaur?

Spyhawk · 2011-08-03 08:45:40

That's something I'd like to include in a next release, but I haven't taken time to make one yet. Any contribution is welcome :]

Last edited by Spyhawk (2011-08-03 09:23:32)

Berseker · 2011-08-03 15:17:16

maybe by modifying an old clyde or bauerbill bash completion files, the job could be easy!
anyway thanks for your work!

tacticalbread · 2011-08-03 15:37:55

Don't forget ZSH completion. :P

clyde also has that, so it should be easy. :D

Arch Linux

#1 2011-05-21 17:36:16

pacaur - an AUR helper that minimizes user interaction

#2 2011-05-22 00:19:04

Re: pacaur - an AUR helper that minimizes user interaction

#3 2011-05-28 12:50:42

Re: pacaur - an AUR helper that minimizes user interaction

#4 2011-05-28 13:54:54

Re: pacaur - an AUR helper that minimizes user interaction

#5 2011-06-23 07:56:24

Re: pacaur - an AUR helper that minimizes user interaction

#6 2011-07-04 14:12:22

Re: pacaur - an AUR helper that minimizes user interaction

#7 2011-07-04 14:41:23

Re: pacaur - an AUR helper that minimizes user interaction

#8 2011-07-04 18:32:12

Re: pacaur - an AUR helper that minimizes user interaction

#9 2011-07-04 21:19:13

Re: pacaur - an AUR helper that minimizes user interaction

#10 2011-07-21 12:39:32

Re: pacaur - an AUR helper that minimizes user interaction

#11 2011-07-21 13:02:56

Re: pacaur - an AUR helper that minimizes user interaction

#12 2011-07-21 13:12:14

Re: pacaur - an AUR helper that minimizes user interaction

#13 2011-07-21 13:16:26

Re: pacaur - an AUR helper that minimizes user interaction

#14 2011-07-22 16:06:57

Re: pacaur - an AUR helper that minimizes user interaction

#15 2011-07-29 12:16:49

Re: pacaur - an AUR helper that minimizes user interaction

#16 2011-07-30 06:43:31

Re: pacaur - an AUR helper that minimizes user interaction

#17 2011-07-30 08:06:10

Re: pacaur - an AUR helper that minimizes user interaction

#18 2011-07-31 16:10:35

Re: pacaur - an AUR helper that minimizes user interaction

#19 2011-08-02 03:22:09

Re: pacaur - an AUR helper that minimizes user interaction

#20 2011-08-02 03:32:03

Re: pacaur - an AUR helper that minimizes user interaction

#21 2011-08-02 05:30:54

Re: pacaur - an AUR helper that minimizes user interaction

#22 2011-08-03 07:56:34

Re: pacaur - an AUR helper that minimizes user interaction

#23 2011-08-03 08:45:40

Re: pacaur - an AUR helper that minimizes user interaction

#24 2011-08-03 15:17:16

Re: pacaur - an AUR helper that minimizes user interaction

#25 2011-08-03 15:37:55

Re: pacaur - an AUR helper that minimizes user interaction

Board footer