Minimal AUR manager

mvtab · 2024-06-10 14:01:38

Hi guys,

I made a minimal manager for AUR packages that I thought I'd share with you.
I did this for fun and I'm currently using it in my .bashrc. I know there are other package managers like yay and the rest, but I actually want to do the compiling myself, I just needed something to make it easier to do bulk compiling and actually later updating what I compile.

What do you guys think? Could something like this be useful for other people? What is it missing? What does it do too much? What should be different?
Any kind of constructive criticism is highly appreciated.

https://github.com/mvtab/aur-functions

Cheers

Trilby · 2024-06-10 18:20:06

In aur-install there should be no need to test for dependencies on every single invocation of the function. A first improvement would be do define the function conditionally, i.e. change from:

aur-install() {
   pacman -T "${REQUIRED_PACKAGES[@]}" || ( echo missing packages listed above; return 1; )
   # ... do stuff here
}

To:

aur-install() {
   # just do stuff here
}
# then if needed, redefine the function to just give a warning message when called
if pacman -T "${REQUIRED_PACKAGES[@]}" >/dev/null; then
  aur-install() { echo "Please install the missing packages: $(pacman -T "${REQUIRED_PACKAGES[@]}")";  return 1; }
fi

Also note I ditched looping over packages one by one to check them to instead using `pacman -T` to filter for any missing packages.

Of course none of this should really be necessary: this is your system and you are putting it in your bashrc. You know ahead of time whether those dependencies are installed, so while checking every time the shell is loaded is better than check every single time the function is invoked, I'm not sure that either of these make sense.

On more of a big-picture logic level, I've never understood the desire to maintain a text file with a list of AUR packages installed. Just use the output from `pacman -m`. Some of these may not be from the AUR, but that's fine, you can still check. This way it doesn't matter if something was installed from the AUR and later dropped from the AUR or moved to a main repo, nor does it matter if a package you have installed from the main repos is dropped to the AUR, etc. Every package that is not native should be eligible for attempted upgrade from the AUR regardless of where it originated. This also greatly simplifies maintenance of the list of alleged AUR packages ... it's simplified by simply not doing it, it serves no purpose.

I also have my own AUR tool written in bash, all it does is search, check for updates, and download build files, but the full logic of it is just the following:

#!/bin/sh
#... string variables (mostly jq format strings) left out here

cmd=$1
shift
case $cmd in
   -s|-Ss|search)
      curl -s "${url}type=search&arg=${1}" \
         | jq  -r ".results[]|select (.Description|contains(\"$2\")) | $search_fmt" ;;
   -i|info)
      curl -s "${url}type=info$(printf '&arg[]=%s' "$@")" \
         | jq -r "$info_fmt" | column -tLl 2 ;;
   -d|downoad)
      git clone "https://aur.archlinux.org/${1}.git" /tmp/${1} ;;
   -u|update)
      pacman -Qm | sort >| /tmp/local.pkgs
      curl -s "${url}type=info$(printf '&arg[]=%s' $(cut -f 1 /tmp/local.pkgs))" \
         | jq -r '.results[]|.Name+" "+.Version' \
         | sort | join /tmp/local.pkgs - \
         | while read pkg a b; do
               case "$(vercmp $a $b)" in
                  -1) printf "$newer_fmt" "$pkg" "$a" "$b" ;;
                  1)  printf "$older_fmt" "$pkg" "$a" "$b" ;;
               esac
            done ;;
   *) printf "$help" ;;
esac

Last edited by Trilby (2024-06-10 19:06:18)

Lone_Wolf · 2024-06-11 09:45:31

I'd change the naming of the AUR_REMOVE_DEPENDENCIES options to reflect the risk of removing to much .

A few examples :
safe instead of none
agressive instead of medium
red_flag instead of full

Trilby · 2024-06-11 12:16:31

I second the above - or really the "full" could instead be "nuke-my-system". I've never once had an occasion to use that set of flags for pacman, and I'd advise not hiding such a potentially destructive command behind a script.

But I'd also just not include removal in an AUR tool at all. Once AUR packages are installed, they are just packages managed by pacman - so they can just be removed with pacman. The only reason to remove them with your AUR tool is to maintain your list of installed AUR packages - which is not a good idea as laid out in my previous post. And here's part of why: you can remove one of these packages directly with pacman, and then your list will be compromised. If you just use `pacman -Qm` to get packages that may be candidates to update via AUR, you'll be set.

mvtab · 2024-06-11 20:51:42

I did find the idea with `pacman -T` great, and tried to implement it so:

MISSING_REQUIRED_PACKAGES=$(sudo pacman -T "${REQUIRED_PACKAGES[@]}")
if [[ ! -z ${MISSING_REQUIRED_PACKAGES} ]]; then
echo "[-] ${MISSING_REQUIRED_PACKAGES} are required and not installed. Exiting." >&2
return 1
fi

but luckily it instantly backfired with this error:

[-] makepkg are required and not installed. Exiting.

This is because pacman can't find makepkg installed, but `command -v` simply simulates running the command and therefor can't fail.

And about the whole sanity checks, I regularly change systems or just modify/cripple my regular system so I kinda want to check that I have everything I need before I start compiling for 30 min to then get an error because some stuff is not installed. (Might not really apply to the current required packages but you know)
While pretty primitive, I like to write down the packages managed by the functions in a separate file just to know with uttermost certainty what did I install through the functions. `pacman -Qm` will do the job most of the times, but I also compile stuff completely manually and I don't want to mix those projects with stuff I install over AUR.

Also, you are both right and having a pacman -Rcns in a script is very dangerous, so I removed it completely and changed the remaining ones to none (since -R really does not remove any deps), safe (-Rs) and aggressive (-Rcnsu). And the first version of aur-remove did not include a `pacman -R` call. I added it later because I found it really annoying having to run 2 commands every time I wanted to uninstall a package installed over the functions. (aur-remove x, pacman -R x)

P.S. The functions can handle packages that have been removed manually and they warn you about it:

mvt@alistair:~/git/aur-functions$ sudo pacman -R libcroco
checking dependencies...
Packages (1) libcroco-0.6.13-2
Total Removed Size: 1.19 MiB
:: Do you want to remove these packages? [Y/n]
:: Processing package changes...
(1/1) removing libcroco [###############################################################################################] 100%
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
mvt@alistair:~/git/aur-functions$ aur-remove libcroco
[-] Package "libcroco" not found on system. Skipping.
[+] Package "libcroco" removed from /home/mvt/.src/package_list.
[-] 1 packages were not installed on the system.

Thanks a lot for your inputs!

Last edited by mvtab (2024-06-11 21:12:37)

Trilby · 2024-06-13 18:29:29

mvtab wrote:

This is because pacman can't find makepkg installed

Makepkg isn't a package - it's provided by the pacman package which you already had listed as a dependency.

mvtab wrote:

but I also compile stuff completely manually and I don't want to mix those projects with stuff I install over AUR.

This can't happen - it's impossible. The stuff you compiled "completely manually" will not show up in `pacman -Qm` output. Unless you mean you have PKGBUILDs that are not in the AUR.

Last edited by Trilby (2024-06-13 18:32:03)

Arch Linux

#1 2024-06-10 14:01:38

Minimal AUR manager

#2 2024-06-10 18:20:06

Re: Minimal AUR manager

#3 2024-06-11 09:45:31

Re: Minimal AUR manager

#4 2024-06-11 12:16:31

Re: Minimal AUR manager

#5 2024-06-11 20:51:42

Re: Minimal AUR manager

#6 2024-06-13 18:29:29

Re: Minimal AUR manager

Board footer