The current strategy for handling this involves reserving ids for every package needing users / groups and tracking it on the wiki. The wiki doesn't actually correspond well to the state of packages in the repositories, as it's missing quite a few users / groups and has plenty that are not used by any official package. I wanted to start moving away some more services from root, but I think this needs to be dealt with first. I suggest reserving a large range (500-999) for *dynamic* ids, and then moving packages to groupadd -r / useradd -r *without* a hard-wired id whenever possible. Most packages can easily get away with this, because the configuration files only reference it by name and they don't have any packaged files that need to be in the group. An example of a package already using a dynamic id is `git`, but it's very precarious right now because it relies on an unstated assumption that no one is going to reserve high static ids. Luckily, the highest id recorded as reserved in the 0-999 system range is 492, and most of the ids in the lower half are still free. We could make the static range smaller by editing some ids after purging most of them. Debian only has 100 ids reserved for static usage in packages (0-99) with 900 for dynamic ids (100-999). https://www.debian.org/doc/debian-policy/ch-opersys.html Fedora does a 200 / 800 split instead: https://fedoraproject.org/wiki/Features/1000SystemAccounts Regardless of what we decide to do, I think we need *something* written down as the official policy rather than just continuing to hope it works out. One thing to note is that using dynamic ids makes leaving unpackaged files behind (/var/lib/foobar) dangerous if the user/group is deleted since another package will get the id. Fedora deals with this by *never* deleting users/groups... and that led to systemd making the same choice in the sysusers handling. The `userdel` command can be passed -r to wipe out the home directory, which may not be enough to get all the files and may not be sane.