Example on building Arch based image with packages from AUR?

[s3rj1k]

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).

[DaanDeMeyer]

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.

[s3rj1k]

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

[Gibheer]

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.

[s3rj1k]

You could build the AUR packages

I was expecting this to be automated :)

[michaelbeaumont]

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.

[s3rj1k]

@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

[michaelbeaumont]

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?

[s3rj1k]

@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]

@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.

[s3rj1k]

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?

[NekkoDroid]

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.

[michaelbeaumont]

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?

[michaelbeaumont]

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.

[DaanDeMeyer]

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?

It can be run as root, just set EUID=123 to trick its root check.

[michaelbeaumont]

It can be run as root, just set EUID=123 to trick its root check.

/work/prepare: line 26: EUID: readonly variable

[s3rj1k]

@michaelbeaumont maybe fakeroot could help as a value in PACMAN_AUTH ?

[NekkoDroid]

@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>

[michaelbeaumont]

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 pacinstalls --resolve-conflicts not being supported by pacman and not being able to use pacinstall with makepkg but that's another issue.

[s3rj1k]

@michaelbeaumont are you planning to update gist?