Create users at build time

Why should user and group be created at build time? This sounds really weird to me.
Arch packages aren't supposed to be shared? You can very well build a package and not install it immediately.

In any cases, I think this task definitively needs to be made at install time.
That is why it is always done in scriptlets.
Now what you might want to do is somehow unifying this task inside the scriptlets.
If that's the case, please add your proposal with the two functions there :
FS#10375
and maybe edit the wiki accordingly.
--shining 04:42, 19 May 2008 (EDT)

As you can see from the list, Arch has reserved less than 1000 UIDs out of some very large number. useradd assigns UIDs from 1000 to 60000 and systemd-nspawn uses UIDs larger than 65536 for unprivileged containers. So if you use UIDs around 60000 for your own purposes, there is very good chance that it won't conflict with anything. -- Lahwaacz (talk) 07:22, 16 August 2017 (UTC)

Thank you but system UID/GID are defined by SYS_UID_MIN (500) and SYS_UID_MAX (999) (defined in /etc/login.defs) and some tools use those numbers to differentiate between system user and normal user. (and warn if system user is being deleted) Reserving range of system UID/GID for administrator use, helps for coders who develop their own daemons and want to make sure that in future UID/GID do not conflict.

GIDs are now generated dynamically / the static GIDs here are not valid anymore

After recent changes to the filesystem package GIDs are now created by sysusers.d(5). The means, that for example the "users" group does not have a static id of 100 anymore. So, the information here is outdated and needs to be updated to reflect the dynamic id allocation. Either that, or there is a possibilty to set static user ids with sysusers.d, but I haven't investigated this yet.

I'm not following this argument: just because GIDs are created by sysusers.d, why does this mean the users group doesn't have a static id any more? Pgoetz (talk) 11:21, 18 March 2019 (UTC)

Because systemd's basic.conf does not specify the GIDs for most of the groups and Arch's PKGBUILD leaves the configurable values to the default, which leads to dynamic behaviour even for users. -- Lahwaacz (talk) 12:25, 18 March 2019 (UTC)

The sudo group is missing. Other distros have this gid set to 27

For some reason I'm not able to edit this page, but it would be a good idea to include sudo = 27 as per at least Ubuntu/Debian. Pgoetz (talk) 11:24, 18 March 2019 (UTC)

Yes, I've wondered about this. Does this have something to do with upstream? The sudo group is pretty widely used AFAIK to identify sys admins on a system, and the /etc/sudoers file seems to support this by default:

## Uncomment to allow members of group sudo to execute any command
# %sudo ALL=(ALL) ALL

Anyway, for the people coming from other distros who are used to having a sudo group, is there any harm in providing guidelines for what the GID should be to be consistent? Seems like no harm done and useful if included. Nothing in the page description suggests that something which isn't created by default should be excluded. If this is the policy, you might want to mention that in order to avoid having to respond to comments like this. Pgoetz (talk) 12:40, 18 March 2019 (UTC)