[aur-general] Prefered way to create users/groups and handle files ownership

Jeremy Audet ichimonji10 at gmail.com
Tue Feb 4 00:22:43 EST 2014


>>> 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/8084208a93a625dd686b13da1d8a63e934a9c69c


More information about the aur-general mailing list