[SOLVED] makepkg -s with nested AUR deps on "userless" systems

Question

hi..
so for the last two years i was able to solve every Arch Linux problem i had from infos around the wiki, the forum, etc. now i am stuck.
here's the scenario:
i am automating installation of a full systems for headless usage.
no user required and/or wanted.
this works perfectly until i need something special from the AUR.
because if a package from the AUR has no dependencies we can run makepkg as user nobody:
..# sudo -u nobody makepkg
but as soon as we need
..# sudo -u nobody makepkg -s
to resolve dependencies from the AUR this fails. "nobody" has no password, therefore we can not sudo.
my preferred idea would be to create a shortlived dummyuser. but how to get this dummy to behave correctly with creation and entering of the password without actual user interaction? (remember: headless automation)
i would really like to avoid the special workaround of running my own build-server with all the packages i need on different target machines, putting those made packages somewhere on the internet and then be able to download them to the designated machine and "pacman -U" them there.
i hope someone with a similar use-case can give me some hints.
cheers,
grubernd
Last edited by grubernd (2015-05-16 17:17:58)

Answer 1

thanks.
progandy wrote:…or if you use su, then allow password-free su execution for the wheel group (/etc/pam.d/su) and…
nice usage of su, will have to dig more into that and i should be able to not need sudo as an extra package.
but i am really trying to avoid the NOPASSWD route for security reasons.
apologies, i forgot to mention that in my original post.
Trilby wrote:
Why not just script it:
source PKGBUILD
pacman -S --asdeps $depends $makedepends
sudo -u nobody makepkg
thanks. seeing it written down differently showed me the flaw in my wishful thinking:
makepkg can of course resolve dependencies but it cannot ever resolve dependencies where one package in the AUR requires another un-made package from the AUR. just doesn't work. that was the block i had.
although not really beautiful i will just drill down the package-chain and resolve dependencies myself in the installer scripts.
(marking thread as solved)