Creating Your First AUR Package; Doing AUR the Wrong Way

Aug 30, 2019

So, you’ve took the plunge – deciding to grow up a bit more and install your distributions without a graphical user interface. Well, good for you. Us adults don’t need all those pretty colors and buttons.

You’ve been making use of the Arch Linux User Repository. You made it past all the warning messages urging you to beware. You feel weird having a password manager installed on the same computer you’re using AUR programs on…

You have programs in a Git repository you checkout, compile, and copy to “/usr/bin” after every fresh install. You loathe doing this. You’re far too lazy to put up with it any longer. This is the right article for you.

Let’s setup some of the assumptions the author is going to make about the software and programs you want to publish to the AUR.

​1. Your software will be one final, self-contained binary. If your chosen programming language toolchain doesn’t support this I recommend looking at the Go programming language. It’s so easy for this.

​2. Everything you need to build your softwares is available within the AUR itself. Think any build tools you may need. If you’re writing C things are probably available from within “base-devel” alone. You’ll need this for future commands we will use (“makepkg”). Go ahead and install this now if you don’t already have it.

pacman -S base-devel

​3. All the code to build your softwares will reside in its own Git repository. This point especially will make it dead simple for us. It’s not the only option but will help this guide remain brief (for example Subversion or Mercurial could be used – or even just a tar file – as long as the code is web accessible).

Okay! Let’s get to it. First order of business is creating your AUR user account. Visit the URL below to accomplish this part. Don’t forget your ssh-rsa keys. You can do it, I believe in you. Please return once you’ve completed this.

Great, awesome. I’m proud of you for getting this far. There’s still a tad more to complete. Not a lot – I swear.

Now you’ll need to “git clone” your AUR package – but it doesn’t exist! Sort of… What do you want your package name to be? For this example I’ll be walking you through the creation of my “line” package on the AUR.

This is what I did to initialize the AUR package. Change the name “line” below to your package name.

git clone ssh://

You now have a folder called “line” (no you don’t – hopefully – you should have changed this to your package name). I’ll assume it’s “line” for ease of explaining what to do from now on.

You probably already have another Git repository setup for your project. If not, well, go do that and return please. You are strong and intelligent!

You’ve returned, or perhaps you’re a sane person that likes version controlled code. I hope it’s the latter. I recommend putting our newly cloned repository from as a submodule to your main project’s repository. You don’t have to. I don’t care what you choose here.

We need to create a file called “PKGBUILD” in the repository we cloned.

cd line 

Now lets open this newly created file with our favorite text editor. Vi, right?


Enter a comment with a “#” at the beginning of the line. Your first comment should look like this:

# Maintainer: Evan M Jones <>

It’s just a nicety. Replace your name and email please. :-)

Now, here’s the “line” program’s “PKGBUILD” – you’ll see it has a Git repository specified. You’ll change this to yours. You’ll also change the “pkgname”, “pkgver”, “pkgrel”, “epoch”, “pkgdesc”, “license”, and “makedepends” to your liking. I’m letting you spread your wings on this one a bit. Once again you are smart! Very intelligent. I have no doubts. You have my support. On the off chance you stumble and cannot break free from some Hell you have found yourself in – call me – (208) 457-2203. Most times are fine. I’ll get back to you if not. We’ll figure it out together.

The “pkgver” function you probably won’t change. The “make” command within the “package” function you probably will! This will be the “build” process of your package – or the set of commands that will produce your executable. The “install” lines below I’ll get to later.

Finally, here’s the file:

# Maintainer: Evan M Jones <>
pkgdesc="A dead simple line printer."
makedepends=('git' 'gcc')

pkgver() {
  cd $pkgname
  printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"

package() {
  cd $pkgname
  install -D -m644 license.txt "$pkgdir/usr/share/licenses/line/LICENSE"
  install -D -m755 line "$pkgdir/usr/bin/$pkgname"

You’ve made your modifications. Great. Within the “package” function you’ve specified all commands needed to build your executable. Are you compiling a Go program? Probably looks something like “go build” then, yeah? No bother if not, as long as we have the sweet, sweet binary afterwards. Now – what of those “install” lines? That’s truely the magic here. If you display the Man page you’ll see:

install - copy files and set attributes

Okay, well, we could have guessed that but that’s really all there is to it. To get your packages into the correct locations for your users. You probably guessed the “-m644” and “-m755” bits pertain to file permissions… and yep. Any type of readable text file (such as a license) you should give a permission of “644” or “Owner read/write, group read, and world real.” and for the executable itself a permission of “755” or “Owner execute/read/write, group execute/read, and world execute/read.”

Erm, think that’s all – no? Yes. Let’s test. Within the directory of your “PKGBUILD” run:


Now… make sure your repository for your project is up to date… Okay, great. Up to date. Then let’s run it.


Any errors? No? Ah, yes? Okay. My preferred search engine is

but you can use whatever to diagnose. I’m pretty bad at predicting the future so I cannot assist in this document at the moment with any errors you had. So search! Effectively searching the web is a crucial skill to have – but once again if you find yourself in some dreaded ring of Hell, feel free to call me. That’s (208) 457-2203.

All the errors are now resolved. You’ve even learned a couple things along the way. Wonderful. Let’s give it a final run. Make sure you don’t have the program actually installed on your system. In my case for “line” that was a good old:

rm /usr/bin/line

It’s uninstalled, so lets reinstall it with the “PKGBUILD” – we’re almost there!

makepkg -si

Does it work? Beautiful. Does it not? Repeat our steps from earlier – specifically the ones about searching the web.

It’s ready for the AUR. Do NOT “git add/commit/push” just yet. I made this mistake you might be about to make. If you attempt to push your “PKGBUILD” to the AUR without having a “.SRCINFO” file all future "git push"s will fail – even if future pushes have this “.SRCINFO” file. Lets generate that real quick.

makepkg --printsrcinfo > .SRCINFO

Nice, that was all. Lets continue.

git commit -m "Feat(AUR release): This is a triumph." # :-) 
git push

Well congrats, you’ve done it. Well, uhm, maybe lets do a final test. Remove your program from your computer once again.

rm /usr/bin/line

Install your package through AUR this time. My favorite way to use the AUR is via “yay” – if you don’t have “yay” installed check this link out. I highly recommend it.

After “yay” is in fact installed use it!

yay -S line # your package name here of course.

Does your program work? Fantastic.

I hope you’ve learned a few things from this journey. I sure did. Anything you might have learned that were not because of this document I urge you to put online somewhere so future us could perhaps learn from or remember again.