As for a better solution? Hmm. `install` (and probably other tools too) can reference user and group names directly. [...] The problem with that is that the uid/gid for the permissions will be computed on the machine where the package is built, [...] It won't work for packages from AUR either. `install` would be called before .install script is able to useradd and groupadd. Only package updates would work.
Aaah. What you are saying finally clicked, and I think I have a solution. My (possible?) solution relies on this point: all PKGBUILD functions must be runnable by `makepkg`, and all .install functions must be runnable by `pacman`. As a result: * One can perform system-independent actions in the PKGBUILD functions. This includes dictating where files should be installed. * One can perform system-dependent actions in the .install functions. This includes assigning an owner to a file (and, therefore, touching user IDs). I've rewritten the inspircd package so that file ownership is assigned in the .install file. This change means user ID and group ID numbers are never explicitly stated. You can see the resultant package [1] and how it differs from the original. [2] I've tested the package on my machine, and it seems legit. Thoughts? By the way, namcap emits an enormous number of warnings, and inspircd fails to start via systemd. This occurs regardless of whether I use the existing or updated package. (and yes, I obeyed the dictates in the post_install message) [1] https://github.com/Ichimonji10/PKGBUILDs/tree/inspircd/inspircd [2] https://github.com/Ichimonji10/PKGBUILDs/commit/8084208a93a625dd686b13da1d8a...