Toggle menu
Toggle preferences menu
Toggle personal menu
Not logged in
Your IP address will be publicly visible if you make any edits.

Arch User Repository: Difference between revisions

From atl.wiki
(added topic AUR Helpers)
m (Add link)
 
(17 intermediate revisions by 4 users not shown)
Line 1: Line 1:
AUR which is also known as the '''A'''rch '''U'''ser '''R'''epository is a community-driven repository of PKGBUILDs, anyone can upload a package to the AUR (we will talk about how to do that in this article) and anyone can take down a package too from the AUR which just a simple letter to the mailing list (which stats say that at least 2-3 people are always active trying to look out for malicious PKGBUILD files). Basically, all the PKGBUILD is, it's a way to create an Arch Package, typically having an extension of <code>.pkg.tar.zst</code> (pkg meaning package, tar being a way to merge multiple files/folders into one, zst being a way to compress the file). Such a package with that extension can be installed via the command <code>sudo pacman -U <file>.pkg.tar.zst</code>. However, we would not be going in detail about that.
The [https://aur.archlinux.org/ '''Arch''' '''User''' '''Repository'''] (AUR) is a community-driven repository for [[Arch Linux]] users. It contains package descriptions ([[PKGBUILD]]s) that allow you to compile a package from source with [[makepkg]] and then install it via [[pacman]].<ref name=":0">[https://wiki.archlinux.org/title/Arch_User_Repository "Arch User Repository"]. Arch Linux.</ref>


AUR is also very much known to have broken packages (as later said in this article, you can easily add a package to AUR with 0 pushbacks 90% of the time), however if you read the PKGBUILDs (with an AUR helper that gives you the option to do so) then you can easily figure out if it will install or not. In a simple context, the average PKGBUILD will have two functions, it will be structured and functioned just like a regular bash script with metadata at top and two functions below, first function is the <code>prepare()</code> function and the other is <code>package()</code> function, to be short : the prepare function creates a directory for the package it is supposed to make and then adds all binaries, config files into how pacman will understand, the package function will just add final scripts, make the package (via <code>makepkg</code>) and then install it through pacman, however this is not always the case since all PKGBUILDs are just like regular bash scripts, you can just have a prepare function to check the files downloaded through source and the package function just putting the files in user directories, this way you won't need root permissions at all. We will see that in detail.<ref>https://wiki.archlinux.org/title/Arch_User_Repository</ref>
The AUR also has its own voting system. All packages are eligible for adoption by a Package Maintainer for inclusion in the <code>extra</code> repository, and the vote count is one of the considerations in that process. [[Package|Packages]] that enter the extra repository can be directly installed with [[pacman]].<ref name=":0" />


=== Significance ===
=== How does it work? ===
AUR being one of the biggest package sources in the Linux community, it has over 60,000 packages and active volunteers to quality check the unfiltered packages. AUR packages are very creative in their own regard also, from people managing to install packages from other formats (.deb) where it's not even made for Arch Linux<ref>https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=google-chrome</ref> to people using Windows Electron applications and modifying it to work on Linux<ref>https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=deezer</ref>, it is no surprise that you can find almost any package possible on the AUR.
The Arch User Repository or the AUR, unlike your regular repository, '''does not host made packages''' but rather it hosts PKGBUILDs that can be used to make packages, these PKGBUILDs contain metadata at the top and mainly two functions/methods:


=== Safety ===
* <code>prepare()</code> : This function prepares your package folder which is the extracted view of a typical package.
With the great power of the AUR, you will be surprised by how secure it is, most people say it is very unsafe, however if you get the habit of reading the PKGBUILD files before installing them, you will never run into issues, but this is not even that severe of a security flaw due to how many people are always checking new packages submitted.
* <code>package()</code> : This function adds basic metadata (optionally verification keys like SHA256 ones) and then generates the package.


The main issue starts with a famous term "dependency hell" which to be short means "installing separate packages that require a certain dependency of a specific version but they both have separate version requirements so you end up with a broken installation". Yeah, it sounds very complicated, because it is. Basically, if you have any 2 separate packages, one could be from your extra or core repositories (check the [[Pacman#Repositories|pacman]] page to learn about default repositories) and the other one could be from the AUR, well if the package maintainer of the AUR package and the package from the extra's repository, let's say depends on <code>ffmpeg</code> and it requires a very old version, well since the packages on the extra's repository are always kept up-to-date as soon as possible, you might end up having a "dependency hell" where pacman wants to use a newer version for the package in extra repository but the AUR package requires an older version and then you end up with a corrupted package and if the package is an important package for the system, you will end up with a full corrupted install.
The surprising part about the AUR is that most packages do not need to follow this style, the packages can just directly copy configuration and binary files directly to their respective places without requiring to make a package. In fact because of the flexibility of AUR packages, you can make your own package by just using a package converter and cloning some package not made for Arch Linux and just convert the package into an Arch-compatible one. It sure works! You can even package apps by manually editing the files of a package and just use that. Unlike any other packaging format, PKGBUILDs can be installed without root too because they are indeed just scripts. It is however suggested to properly read the PKGBUILDs you get from the AUR for your own safety.


=== Naming Scheme ===
=== Installation of packages ===
This is a very strictly enforced naming scheme in the AUR and it is basically adding a suffix that determines the package type.. The main ones are:
On this page, we use the officially recommended method, though you can also install packages from the Arch User Repository with AUR helpers. While these tools can simplify the process and save time, they may introduce security risks and potential system instability if not used carefully.


* <code>-git</code> : which means that the package will clone and build manually through a git repository. (Most likely GitHub or GitLab repository)
To start, you must be on an Arch Linux system and install the following packages:
* <code>-bin</code> : which means that the package will just fetch a pre-compiled binary and install the configuration files. (RECOMMENDED)
* <code>git</code> : This will be used to clone a package from the AUR.
* No Suffix : which means that the package is either proprietary or it is compiling or source-based package. Just see the PKGBUILD for this one.
* <code>base-devel</code> : This should be probably installed but if it isn't, you must do. This gives us the tools to make PKGBUILDs.


Now, ideally you would pick the <code>-bin</code> package or a proprietary package with no suffix meaning that it will just use binary anyways (because you cannot manually compile programs without source code), this is because it is much faster to use a pre-compiled binary as opposed to letting it manually clone, build and install.
You can [https://aur.archlinux.org/packages?O=0&K= search the AUR] and choose your package, we will take the <code>visual-studio-code-bin</code> package as an example. You can pick any package you like and just replace the name.


=== Installing AUR packages ===
To install, follow these steps:
This might be a little complicated for those who aren't familiar with the way Arch Linux packages work but it is quite easy to grab.


Basically, if you used <code>archinstall</code> for your system, you probably have this package called <code>base-devel</code>, it means base development and this is what allows us to install packages from the AUR repository, you must have <code>git</code> installed too since we need to clone packages. If you installed Arch Linux the manual way you have probably pacstrapped it because it is recommended in the ArchWiki, if you haven't then please install <code>base-devel</code> through pacman.
* <code>git clone https://aur.archlinux.org/visual-studio-code-bin.git</code> : This will clone the package from the AUR and will be stored in your current directory.
* <code>cd visual-studio-code-bin</code> : This will put you into the directory of your cloned package.
* <code>makepkg -si</code> : <code>makepkg</code> is one of the main utilities to install any AUR package, the <code>-s</code> flag syncs any dependencies of your package (so it won't give you an error if the package dependencies are not installed) and the <code>-i</code> flag will install the package generated if your package is made and has no errors.


To summarize, installing any package from AUR is basically getting a PKGBUILD that tells the system to create a package and install, it is kind of weird but essentially an AUR package is instructions to make an Arch Linux package. We will try to install the <code>waterfox-bin</code> package because it is not available in the extra or core repository. (To understand the <code>-bin</code> suffix, please check the naming scheme above).
And that's it, you can run the program and check it out! You can do this with any program and it will work!


To install <code>waterfox-bin</code> via the AUR, you have to install <code>git</code> and <code>base-devel</code> via pacman as said earlier. Then you will use <code>git clone <nowiki>https://aur.archlinux.org/waterfox-bin.git</nowiki></code>, that will clone the PKGBUILD for Waterfox and put it in your current directory. Use <code>cd waterfox-bin</code> to go inside that directory and then run <code>makepkg -si</code> which will use <code>makepkg</code> to make the package and ask to install it. What we are doing here is using a single file to build an Arch Linux package for us and install that. This will successfully install the package. Yeah, it was that easy, to make it more easy however, we have AUR Helpers.
To simplify the process, AUR helpers have been created. While we won't cover them in detail, here's a brief overview: the basic AUR helpers can search and download packages, the more advanced ones can search, build, and install packages, and the most commonly used ones, known as pacman wrappers, can search, build, update, and manage system packages. This means you can update your entire system using these tools. However, [[pacman]] is still required as these helpers essentially use pacman to perform their tasks.


=== AUR Helpers ===
=== Package Naming ===
There are majorly 8 AUR helpers but only 3 most commonly used ones, namely:
All packages have either one of three suffixes:


* <code>yay</code><ref>https://github.com/Jguer/yay</ref> (Yet another yogurt) : This is the most widely used AUR helper and is also surprisingly the most downloaded package on the AUR! It is written in go but it has a lot of propaganda behind it that it is dying and it is dead, one of the main developers from <code>yay</code> actually started <code>paru</code>, which is our next AUR helper.
* <code>-bin</code> : These packages are pre-compiled and are not built by source.
* <code>paru</code><ref>https://github.com/morganamilo/paru</ref> : This is by far the second most recognized AUR helper in the community and it is the most recent one, being made by one of the main developers of <code>yay</code>, it should be no surprise here that it is fully feature packed and offers a lot of features, we recommend this the most due to how it always forces you to review PKGBUILDs that you try to install, this always keeps you safe and forces you to be careful. It can get annoying sometimes but it is a very good habit to maintain especially if you like to scavenger hunt new packages every day. This AUR helper is written in Rust.
* <code>-git</code> : These packages are generally not recommended as they are unstable packages and are not intended for regular use however they can have new features or bug fixes.
* <code>pacaur</code><ref>https://github.com/rmarquis/pacaur</ref> : This is out of date nowadays and does not receive any support due to it lacking a lot of features, originally it was started as an AUR helper that minimizes user interaction but it is not being actively used right now and it is written in Bash. It is quite nostalgic to a lot of people so it is still fairly widely used.
* No Suffix or other suffix : These packages are stable packages where they have been tested and are proven stable.


There are other AUR helpers but these 3 are the most common and easiest to use. We will focus with <code>paru</code> because of it being the most verbose AUR helper, it has some unsafe flags but you won't encounter it in most cases.
You should also look out for 'marked as orphaned' or 'marked as out of date' packages as they are commonly found with packages that have the <code>-git</code> suffix. The binary ones are recommended for every package and are probably the most frequently updated ones.


To install an AUR helper, you do it just like a package except we will use the <code>-bin</code> versions of the package, see this is what most beginners in the community do wrong, they install the regular without <code>-bin</code> suffix AUR helper package build file. As we saw earlier at naming schemes, without that suffix, the package will be manually cloned and compiled then put into your system, but using the <code>-bin</code> packages just use a pre-compiled binary.
=== Creating a package ===
To create a PKGBUILD for the AUR it is quite simple, you can follow these steps:


This is a guide to install <code>paru</code> AUR helper but you can use the same with any AUR helper by just switching the names.
* Make a folder for your package separately and make a file inside that folder just called <code>PKGBUILD</code> (case-sensitive).
* Inside that file add required metadata<ref>https://wiki.archlinux.org/title/PKGBUILD</ref> and/or optional ones for your PKGBUILD.
* Then you need to add the functions, these look like bash functions and scripts of similar kind, like we said earlier about the <code>prepare()</code> and <code>package()</code> functions but we do also need some more important functions like <code>pkgver()</code>, <code>build()</code> and <code>check()</code> depending on what kind of package you are trying to make. These functions are more properly explained on the Arch Wiki.<ref>https://wiki.archlinux.org/title/Creating_packages#PKGBUILD_functions</ref>
* And then, just check your package, save it, then run the same command as before <code>makepkg -si</code> to check the package. If it does build and prompts you to install that means it worked! You can also use namcap<ref>https://wiki.archlinux.org/title/Namcap</ref> to check errors in the package.
* To submit your package to the AUR, create an account on the AUR properly and setup the SSH keys. Please do also make sure that the package you are making is not already made.
* Once done, just open your terminal and run git clone <code>https://aur.archlinux.org/&#x3C;your_package_name&#x3E;.git</code>, you might think it is not made but what you are actually doing here is sending a request to the AUR to create a package and clone it. When the AUR receives a clone request for a package not already made, it just creates a new blank repository, make sure it is created via your AUR SSH key. Also, make sure to add the suffix as mentioned earlier since the packages are actively moderated by volunteers and they may strike your package down.
* Copy the PKGBUILD you made into this folder you have cloned, go inside that folder and run <code>makepkg --printsrcinfo > .SRCINFO</code>. This will create a required .SRCINFO file that just contains general metadata for AUR such as description and other things. Then, you can just add the two files via git, make a commit with a message like "Initial commit" and then push it. It should work and the package should be visible on the AUR in a few minutes. Please note that the AUR will not permit the package on the AUR repository if it does not find the .SRCINFO file.


# Run this command <code>sudo pacman -S base-devel git --needed --noconfirm</code> . This command looks very scary but it just installs git and the required package commands we want, it will not ask the user for any <code>(y/n)</code> but rather just do it and it will also prevent reinstalling so if you have both of these installed, it will just say that it is already installed and that it is skipping.
If you want to delete, merge, orphan or mark your or any package out of date, you can send a request to the AUR mailing list.
# Then you run <code>git clone https://aur.archlinux.org/paru-bin.git --depth=1</code>, that will download our PKGBUILD from the AUR, this is one of the most common beginner mistake, they complain it takes too long but they never download the binary PKGBUILD script. The <code>--depth=1</code> flag is to just tell git to not get previous commit information and only get commit information from the last <n> number of commits, which here is 1 since we will just build and remove that directory. Once it is cloned, <code>cd</code> into that directory.
# Once you are inside the directory, run <code>makepkg -si</code> and then wait, depending on your network you should take roughly 2-10 minutes to download and install. After it is done, just run <code>paru</code> and check. (if you do leave your devices and when you come back you see that it was waiting for root permission and that it had quit now saying timeout exceeded, you can just do a <code>ls</code> and check, there should be a package file [extension: <code>.pkg.tar.zst</code>], if it does then just do <code>sudo pacman -U <file>.pkg.tar.zst</code>)


Done! Now you can enjoy installing packages. With paru you might want to change this one main thing, go into your <code>/etc/paru.conf</code> file with your favorite text editor. The most important thing you have to change is:
=== Safety ===
 
As seen, you can publish your package to the AUR with minimal checks beyond the general SRCINFO file. Although the AUR is actively moderated by volunteers, some malicious packages may not be caught. It is advisable for users to read the PKGBUILDs they use from the AUR to ensure their safety.
Since paru by default when just ran with example: <code>paru brave</code>, it will by default print from first to last but there's a problem, now you cannot get the most relevant one to your search and end up with a lot of useless packages at the start, well you should un-comment the line where it says <code>BottomUp</code> in the configuration file, if it is not there just add a new line under the options category and write <code>BottomUp</code>.
 
Other than that you can play around and add or remove flags however you like but don't forget to add/uncomment <code>Color</code> from the <code>/etc/pacman.conf</code> file because yes that effects to paru also. You can add <code>ILoveCandy</code> for quirky progress bars.


=== Further Dive into AUR Helpers ===
Users are encouraged to report any malicious packages that may have been missed to the AUR mailing list. The AUR hosts over 60,000 packages, and user reports help maintain its security and reliability.<references />
(WORK IN PROGRESS)
[[Category:Terminology]]

Latest revision as of 18:24, 11 June 2024

The Arch User Repository (AUR) is a community-driven repository for Arch Linux users. It contains package descriptions (PKGBUILDs) that allow you to compile a package from source with makepkg and then install it via pacman.[1]

The AUR also has its own voting system. All packages are eligible for adoption by a Package Maintainer for inclusion in the extra repository, and the vote count is one of the considerations in that process. Packages that enter the extra repository can be directly installed with pacman.[1]

How does it work?

The Arch User Repository or the AUR, unlike your regular repository, does not host made packages but rather it hosts PKGBUILDs that can be used to make packages, these PKGBUILDs contain metadata at the top and mainly two functions/methods:

  • prepare() : This function prepares your package folder which is the extracted view of a typical package.
  • package() : This function adds basic metadata (optionally verification keys like SHA256 ones) and then generates the package.

The surprising part about the AUR is that most packages do not need to follow this style, the packages can just directly copy configuration and binary files directly to their respective places without requiring to make a package. In fact because of the flexibility of AUR packages, you can make your own package by just using a package converter and cloning some package not made for Arch Linux and just convert the package into an Arch-compatible one. It sure works! You can even package apps by manually editing the files of a package and just use that. Unlike any other packaging format, PKGBUILDs can be installed without root too because they are indeed just scripts. It is however suggested to properly read the PKGBUILDs you get from the AUR for your own safety.

Installation of packages

On this page, we use the officially recommended method, though you can also install packages from the Arch User Repository with AUR helpers. While these tools can simplify the process and save time, they may introduce security risks and potential system instability if not used carefully.

To start, you must be on an Arch Linux system and install the following packages:

  • git : This will be used to clone a package from the AUR.
  • base-devel : This should be probably installed but if it isn't, you must do. This gives us the tools to make PKGBUILDs.

You can search the AUR and choose your package, we will take the visual-studio-code-bin package as an example. You can pick any package you like and just replace the name.

To install, follow these steps:

  • git clone https://aur.archlinux.org/visual-studio-code-bin.git  : This will clone the package from the AUR and will be stored in your current directory.
  • cd visual-studio-code-bin : This will put you into the directory of your cloned package.
  • makepkg -si : makepkg is one of the main utilities to install any AUR package, the -s flag syncs any dependencies of your package (so it won't give you an error if the package dependencies are not installed) and the -i flag will install the package generated if your package is made and has no errors.

And that's it, you can run the program and check it out! You can do this with any program and it will work!

To simplify the process, AUR helpers have been created. While we won't cover them in detail, here's a brief overview: the basic AUR helpers can search and download packages, the more advanced ones can search, build, and install packages, and the most commonly used ones, known as pacman wrappers, can search, build, update, and manage system packages. This means you can update your entire system using these tools. However, pacman is still required as these helpers essentially use pacman to perform their tasks.

Package Naming

All packages have either one of three suffixes:

  • -bin : These packages are pre-compiled and are not built by source.
  • -git : These packages are generally not recommended as they are unstable packages and are not intended for regular use however they can have new features or bug fixes.
  • No Suffix or other suffix : These packages are stable packages where they have been tested and are proven stable.

You should also look out for 'marked as orphaned' or 'marked as out of date' packages as they are commonly found with packages that have the -git suffix. The binary ones are recommended for every package and are probably the most frequently updated ones.

Creating a package

To create a PKGBUILD for the AUR it is quite simple, you can follow these steps:

  • Make a folder for your package separately and make a file inside that folder just called PKGBUILD (case-sensitive).
  • Inside that file add required metadata[2] and/or optional ones for your PKGBUILD.
  • Then you need to add the functions, these look like bash functions and scripts of similar kind, like we said earlier about the prepare() and package() functions but we do also need some more important functions like pkgver(), build() and check() depending on what kind of package you are trying to make. These functions are more properly explained on the Arch Wiki.[3]
  • And then, just check your package, save it, then run the same command as before makepkg -si to check the package. If it does build and prompts you to install that means it worked! You can also use namcap[4] to check errors in the package.
  • To submit your package to the AUR, create an account on the AUR properly and setup the SSH keys. Please do also make sure that the package you are making is not already made.
  • Once done, just open your terminal and run git clone https://aur.archlinux.org/<your_package_name>.git, you might think it is not made but what you are actually doing here is sending a request to the AUR to create a package and clone it. When the AUR receives a clone request for a package not already made, it just creates a new blank repository, make sure it is created via your AUR SSH key. Also, make sure to add the suffix as mentioned earlier since the packages are actively moderated by volunteers and they may strike your package down.
  • Copy the PKGBUILD you made into this folder you have cloned, go inside that folder and run makepkg --printsrcinfo > .SRCINFO. This will create a required .SRCINFO file that just contains general metadata for AUR such as description and other things. Then, you can just add the two files via git, make a commit with a message like "Initial commit" and then push it. It should work and the package should be visible on the AUR in a few minutes. Please note that the AUR will not permit the package on the AUR repository if it does not find the .SRCINFO file.

If you want to delete, merge, orphan or mark your or any package out of date, you can send a request to the AUR mailing list.

Safety

As seen, you can publish your package to the AUR with minimal checks beyond the general SRCINFO file. Although the AUR is actively moderated by volunteers, some malicious packages may not be caught. It is advisable for users to read the PKGBUILDs they use from the AUR to ensure their safety.

Users are encouraged to report any malicious packages that may have been missed to the AUR mailing list. The AUR hosts over 60,000 packages, and user reports help maintain its security and reliability.