:thumbsup:

Hmm, what is the rationale for allocating those statically?

OK, kvm group is used for /dev/kvm and is shared between the initrd and the host system, so it makes sense to use a fixed number.

But qemu seems suspicious. Please explain the use case.

This PR was made to reflect the situation is it is today. I did not really question the status quo.

The guidelines say:
https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_soft_static_allocation:

To allocate a UID and/or GID, file a ticket here for the FPC to evaluate. If the FPC finds that your package needs a soft static UID or GID, they will approve your request and pass it on to the maintainers of the setup package for implementation. Because the number of UIDs and GIDs is limited, you need to justify your package’s need for a soft static uid in the FPC ticket. Explain how the uids and gids are being shared between computers. If applicable, also explain why the program can’t be adapted to use symbolic names (username and groupname) instead. If a specific UID or GID should be used, please mention it and why (for instance, it is the one used by upstream or the one used by other distributions).

We've added UIDs and GIDs for pre-existing allocations before, this is not an exception. Some things just weren't documented or went through the correct process when they made those allocations, but since they're already done, just documenting them is the right thing to do IMO.

But yes, new static allocations should go through FPC ...

Static allocations are bad. If the static allocation is not needed for anything, instead of hardcoding the mistake in packaging guidelines, just convert the package to use a soft allocation instead. So unless there's an actual reason, the guideline change should be reverted and the package should be updated instead.

If the static allocation is not needed for anything, instead of hardcoding the mistake in packaging guidelines, just convert the package to use a soft allocation instead. So unless there's an actual reason, the guideline change should be reverted and the package should be updated instead.

This is going about things from the wrong end. The packaging guidelines should reflect the current reality. If the package is altered to not require a static allocation, then the guidelines can be changed to reflect the reality.

That said, the guidelines often lag reality, as is obvious from the age of this ticket. If those packages are in the process of being fixed then sure, we can save work just by not documenting things. Are those packages in the process of being fixed? It's not really for FPC to push that effort (and I doubt we have the time) but if you're pushing it then great. Please keep us updated.

If nobody is fixing those packages, then let's at least get the guidelines closer to reflecting reality.

I also don't think static allocations are bad. There are many good reasons to have them. For example, static allocations for kvm and qemu are required to ensure portability of data across VM nodes in shared storage setups.

Many of our existing static allocations are in place for reasons similar to that.