An alternative to this is using paclock --run:
paclock --run -- aur build--sync
Locking inside aur-build--sync keeps this implementation detail hidden,
e.g. compare the sudoers rules
NOPASSWD: /usr/lib/aurutils/aur-build--sync
and
NOPASSWD: /usr/bin/paclock --run aur build--sync
where in the latter the path is defined by AUR_LIB_DIR and aur(1)
instead of defined by system policy.
Remote clones are not migrated to local clones and vice-versa. This
process has some subtleties (such as checking if master@{u} is still
available) and is therefore left to the user.
To better reflect this, use an environment variable AUR_FETCH_USE_MIRROR
as a more permanent way to enable local clones than a command-line option.
This is done by splitting out the helper function into auto load functions. To facilitate
this, the Makefile was also refactored, and _aur.zsh was renamed to just _aur.
Helper script to do a shallow clone of the new AUR mirror [1] and
checkout branches one-by-one. Similar to asp(1), this offers the option
to keep local clones for each branch. This is transparent to aur-fetch
and aur-view in particular.
[1] https://github.com/archlinux/aur
This is based on how _git allows extension, though only one of two
mechanisms were copied over (using zstyle was an inferior option as
it doesn't allow completion of the arguments to the user defined
sub commands).
Instead of prefixing several pacsync/pacman commands with `sudo`, wrap
the commands in an `build--sync` helper. When configurating `sudoers`
rules, this is more granular than blanket `pacsync` and `pacman` rules:
only upgrading local repository targets is whitelisted.
Compared to the previous approach, --pacman-conf does not apply to local
repository upgrades. This makes it harder to inadvertendly shoot
yourself in the foot by passing on a potentially world-writeable file to
a privileged process.
A helper can also be overridden through AUR_EXEC_PATH, and called by
other scripts that wish to replicate a restrained local repository
upgrade.
When using sudoers(5) to remove password prompts for select commands,
pacman --config=/tmp/... command-lines are variable and thus require
whitelisting /usr/bin/pacman (opening up `sudo pacman -U` commands), or
--config with arbitrary arguments (e.g. --config=bad.conf).
Use a different mechanism to limit upgrades to the local repository,
which uses fixed command-lines:
1. Propagate new databases with `pacsync custom`
2. Check if any installed packages are to be upgraded with `pacman -Sup`
3. Restrict the targets to the local repository
4. Finally, install upgrades with `pacman -S --noconfirm`
Replacements, if any, will be denied from using --no-confirm.
Compare the (unpublished) pacman commit:
80b118b48b
The command
git rebase origin master
will run `git switch master` before doing anything, whereas
git rebase origin/master
will rebase changes starting from origin/master in the current branch.
Setting this for all builds may cause issues with PKGBUILDs depending on
non-standard PATH locations (set in /etc/profile.d). Set a default value
when running elevated, matching setpriv --reset-env and sudo.
Closes#979
Alad Wenter