Method of auto updating AUR package

twist-rise · 2024-07-14 18:59:19

Hi all

Is this an appropriate way to auto update an AUR package without using an AUR helper?

Thanks

# /etc/systemd/system/update_sonarr.service

[Unit]
Description=Update Sonarr-Develop AUR Package
[Service]
Type=simple ExecStart=/bin/bash /usr/local/sbin/update_sonarr.sh
[Install]
WantedBy=multi-user.target

# /etc/systemd/system/update_sonarr.timer

[Unit]
Description=Run update_sonarr daily
[Timer]
OnCalendar=daily Persistent=true
[Install]
WantedBy=timers.target

# /usr/local/sbin/update_sonarr.sh

#!/bin/bash

# Navigate to the package directory
cd /opt/sonarr-develop || exit

# Update the source
git pull

# Run makepkg as 'nobody'
runuser -unobody makepkg -src

# Source PKGBUILD to get variables
source PKGBUILD

# Determine architecture. Note: Adjust this as necessary if your Arch naming differs.
_arch=$(uname -m)

# Construct the filename. This assumes the package extension is .xz,
# but you should adjust the extension based on the actual output of makepkg.
# Common extensions include .xz, .zst, .gz, etc.
filename="${pkgname}-${pkgver}-${pkgrel}-${_arch}.pkg.tar.xz"

# Install the package with pacman
pacman -U "$filename" --noconfirm

Last edited by twist-rise (2024-07-14 19:00:30)

twist-rise · 2024-07-14 19:01:57

It was made with some prodding of gpt4, which I know is probably frowned upon, as well as reading the wiki.

Lone_Wolf · 2024-07-14 19:55:31

sourcing a PKGBUILD is considered very dangerous and not used by any aur helper.
makepkg does it, but uses special methods that significantly reduce the risk.

Read .SRCINFO to get the needed vars.

Other then that, updating any aur package without vetting the PKGBUILD is a very bad idea .

twist-rise · 2024-07-14 20:04:14

ok thank you for warning me.
I will not do this then.

Last edited by twist-rise (2024-07-14 20:04:26)

twist-rise · 2024-07-14 20:12:18

It would be cool to get an email stating that the AUR has been updated with a diff, so I can go in and run the update perhaps.

Trilby · 2024-07-14 20:12:24

There's also no need to read .SRCINFO if all you want the information for is to install the package: makepkg has an -i flag for that.

While one should (re)check any PKGBUILD before building and update, this is a much bigger concern if you run a script like this that blindly installs new content as root on a daily basis without checking on that content. Running this timer would make it beyond trivially easy for your whole system to be taken over by someone else: most trivially by the maintainer of any aur package you apply this to, but also the upstream source author, or anyone who can manipulate either of these two, or any potential MITM for either of these sources.

Last edited by Trilby (2024-07-14 20:15:13)

twist-rise · 2024-07-14 20:18:29

As I understood it, if I use -i I need sudo as it installs the package on the system.

This meant the script would need to run "sudo makepkg -sirc" perhaps.

It seemed easier to do it the other way around: to make the whole script as root, and then run makepkg without elevated privileges. However I understand it is not a good idea to auto install from AUR. I guess because the changes aren't vetted.

Last edited by twist-rise (2024-07-14 20:19:05)

Lone_Wolf · 2024-07-15 10:14:23

It would be cool to get an email stating that the AUR has been updated with a diff,

AUR supports several types of email notification one of which is 'Notify of package updates' ( check my account while logged into aur) .

Every time a package you have notifications enabled for gets a new commit will then trigger a message.
A diff is not part of the message, but it's a git commit so getting the diff is easy..

Nikolai5 · 2024-07-15 10:45:59

I've installed auracle and use it's "outdated" function as a pacman hook, so after performing a system update it will tell me if any of my foreign AUR packages need looking at, the process of which is the normal manual process of git pulling, checking PKGBUILD, and building. So I still follow the recommendations with regard to the AUR, but with a bit more quality of life.

That is if you don't want to go the email route.

Trilby · 2024-07-15 11:57:27

Note that there can be two very different meanings of an AUR package being "outdated" that seem to be getting conflated here. One is when the actual AUR content changes - i.e., there's an increment to pkgver and / or pkgrel. The other is when an AUR package needs to be rebuilt due to system package (e.g., library) updates even when the AUR package itself has not changed at all.

Then, of course, neither of these covers VCS packages for which the best tool to determine whether they should be rebuilt is /bin/yes.

Alad · 2024-07-16 08:29:53

makepkg does it, but uses special methods that significantly reduce the risk.

This is not true, makepkg sources the PKGBUILD like any other bash script. (The "source_safe" just preserves shell options and checks the exit status of "source".) You could do things like unset PATH, but then you would severely limit what you can do in PKGBUILDs.

Arch Linux

#1 2024-07-14 18:59:19

Method of auto updating AUR package

#2 2024-07-14 19:01:57

Re: Method of auto updating AUR package

#3 2024-07-14 19:55:31

Re: Method of auto updating AUR package

#4 2024-07-14 20:04:14

Re: Method of auto updating AUR package

#5 2024-07-14 20:12:18

Re: Method of auto updating AUR package

#6 2024-07-14 20:12:24

Re: Method of auto updating AUR package

#7 2024-07-14 20:18:29

Re: Method of auto updating AUR package

#8 2024-07-15 10:14:23

Re: Method of auto updating AUR package

#9 2024-07-15 10:45:59

Re: Method of auto updating AUR package

#10 2024-07-15 11:57:27

Re: Method of auto updating AUR package

#11 2024-07-16 08:29:53

Re: Method of auto updating AUR package

Board footer