Open s3rj1k opened 5 months ago
I can review a patch to add this somewhere in docs/ but I don't use the AUR myself so I can't help you with writing the example.
I can review a patch to add this somewhere in docs/ but I don't use the AUR myself so I can't help you with writing the example.
What wound be a best approach to install aur packages, in chroot stage maybe?
Basically one would need one of Pacman wrappers
from https://wiki.archlinux.org/title/AUR_helpers to be installed so that it could be used in chroot to install additional packages.
I am thinking of yay
to copy it from root system so that no manual makepkg would be needed, but it feels like a hack
You could build the AUR packages and place them in a repository. mkosi could then access the packages like any other package repository (core, extra). repo-add is the command you need to build your own repository.
You could build the AUR packages
I was expecting this to be automated :)
I put together a gist of how I'm doing AUR + mkosi using .build
, .prepare
and .postinst
.
Biggest pain points are the "no root with makepkg
" in combination with not being able to sudo -u nobody makepkg
and have makepkg
call sudo
plus the initial install of aurutils
.
@michaelbeaumont Did you consider using other AUR helpers?
Also it would be nice to have native AUR helper support, meaning some kind of glue from mkosi to some other AUR helper
Basically not being able to run any AUR helpers as root and no_new_privileges
leaving makepkg unable to call sudo makes these other AUR helpers not especially useful. aurutils
is flexible enough to split everything into steps and separate out the install steps.
Fully agree on the AUR needing to be easier. Using Arch means using the AUR, even for other distros installing non-package manager managed software is a necessity. Special classing the repo's package manager and making anything else very difficult is not a great strategy for a tool that claims to be for OS images. At least with Arch, working with upstream packages and the AUR are very similar. mkosi
really punishes you for wanting to use both in a similar way.
But the question is really, is making the AUR easier to use something mkosi
would be interested in?
@DaanDeMeyer What can we do about all of this?
I also don't see any real usability for mkosi with arch without sane AUR support.
@DaanDeMeyer What can we do about all of this?
I also don't see any real usability for mkosi with arch without sane AUR support.
I am very happy with mkosi's arch support without ever having needed AUR packages.
I tagged the issue with PRs welcome, feel free to submit a PR to document how to build AUR packages. I doubt we'll merge native support for a specific aur package manager at this point.
feel free to submit a PR to document how to build AUR packages
issue is with no_new_privileges
, can this be mitigated with some extra config option?
makepkg
supports setting the env var PACMAN_AUTH=
to whatever you want, in this case PACMAN_AUTH=env
is enough as that will effectivly just pass through everything directly to pacman
without any elevation.
makepkg supports setting the env var PACMAN_AUTH= to whatever you want, in this case PACMAN_AUTH=env is enough as that will effectivly just pass through everything directly to pacman without any elevation.
Can you be a little more specific? makepkg
can't be run as root, so how does using env
allow it to get the privileges necessary to install packages? What exactly does the call to makepkg
/aur sync
/something similar look like?
I doubt we'll merge native support for a specific aur package manager at this point.
I'm not really sure it requires supporting any package manager really. aurutils
, which is what my gist is using, is just a wrapper around the aurweb interface, git
and makepkg
.
makepkg supports setting the env var PACMAN_AUTH= to whatever you want, in this case PACMAN_AUTH=env is enough as that will effectivly just pass through everything directly to pacman without any elevation.
Can you be a little more specific?
makepkg
can't be run as root, so how does usingenv
allow it to get the privileges necessary to install packages? What exactly does the call tomakepkg
/aur sync
/something similar look like?
It can be run as root, just set EUID=123 to trick its root check.
It can be run as root, just set EUID=123 to trick its root check.
/work/prepare: line 26: EUID: readonly variable
@michaelbeaumont maybe fakeroot
could help as a value in PACMAN_AUTH ?
@michaelbeaumont https://github.com/NekkoDroid/NekkOS/tree/68f6864b4ba93cbde88452dfdf8b64d0bbbe03c9/mkosi.images/mkosi-packages I've written mine mkosi.prepare
in python, but its also possible in regular bash
: invoke makepkg
roughtly as such env EUID=123 PACMAN_AUTH=env makepkg <other-args>
Indeed, that works, thanks. It would be possible to use aur sync
instead of the separate fetch
+ build
steps which would simplify my mkosi.build
. Now I'm running into pacinstall
s --resolve-conflicts
not being supported by pacman
and not being able to use pacinstall
with makepkg
but that's another issue.
@michaelbeaumont are you planning to update gist?
Would be nice to have some example on how to build Arch based image that have packages from AUR (when host that builds image is also Arch linux and of same platform, in case it matters).