Talk:DeveloperWiki:UID / GID Database
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)
Would you mind adding the following group to the list?:
I am using this group to allow access to input events for gizmod in AUR.
Add svn user and group
Just a suggestion: create/reserve UID 44 and GID 44 for snv user (subversion server)
Can we have UID and GID 97 set aside for mailman? http://www.list.org
EDIT: 91 is used for video apparently, changed to 97
It seems gdm creates a group when installing as well. There's a bug against its current behaviour (bug 13690), I really think it should have a group with the same gid as its uid (120).
policykit is incomplete
The UID entry for policykit is missing. It creates both a user (102) and a group (102), only the latter is mentioned on the page.
Pulseaudio creates one user (pulse : 130) and three groups (pulse : 130, pulse-access : 131, pulse-rt : 132).
This package creates a user-level group, there's a bug open for this issue (bug 14787).
Can we have UID and GID 112 set aside for amanda?
Please add userid 52 for cruisecontrol package ()
- grep ossec /etc/group
- grep ossec /etc/passwd
What about packages from AUR?
As I started discussing it at Talk:Arch_Packaging_Standards#Adding_system_users, it would be good to have a clearer process for the addition of system users, and maybe a specific sub-namespace (_e.g._ from 500 to 749) for AUR, as well as some authoritative list to avoid collisions ? Maybe another namespace (750-999?) should also be kept strictly reserved for local uses, so admins can create groups knowing that no upstream ArchLinux package will ever use the ID.