Following the discussion [1], I'd like to remove the policy part of GLEP 81 [2] and replace it with a tree policy. In this bug, I'd like to propose this policy for discussion/vote by the QA team. This is roughly a nicely worded version of the policy proposed in the RFC. === All new user/group accounts must be created via GLEP 81 packages. The existing packages should be migrated on the next version bump or major update. CI system will remind developers to perform the migration. Existing and historical fixed UIDs/GIDs in range 0..999 (used in baselayout or via user.eclass) as listed in uid-gid.txt can be reused as-is in acct-* packages. UIDs and GIDs in range 0..100 are reserved for important system accounts. New assignments in that range need to be explicitly approved by the QA lead, in response to a justified request from the developer. The range 101..500 is provided for regular use by packages. The assignments from this range follow the following rules: 1. A developer can select an arbitrary free UID/GID from this range. If in doubt, it is recommended to select successive numbers from 500 downwards. 2. Unless there is a very good reason not to, matching users and groups should use the same number. It is acceptable to leave gaps in assignments as a result of that. 3. Before pushing the new acct-* packages, the developer *must* push an update to uid-gid.txt adding the 'acct' entry for the desired UID/GID. This serves as a synchronization primitive to prevent collisions. Further UID/GID ranges will be open in the future as the need arises. === [1] https://archives.gentoo.org/gentoo-dev/message/9601d9904bf97d88349d41ab7d3a4eb7 [2] https://archives.gentoo.org/gentoo-dev/message/7e2197c632d42900df525141ae328913
(In reply to Michał Górny from comment #0) > Existing and historical fixed UIDs/GIDs in range 0..999 (used in baselayout > or via user.eclass) as listed in uid-gid.txt can be reused as-is in acct-* > packages. It doesn't make a difference, but shouldn't we say 0..499 here, because there are no existing assignments above that range? > UIDs and GIDs in range 0..100 are reserved for important system accounts. > New assignments in that range need to be explicitly approved by the QA lead, > in response to a justified request from the developer. > > The range 101..500 is provided for regular use by packages. The assignments > from this range follow the following rules: Again, why 101..500 and not 101..499? > 1. A developer can select an arbitrary free UID/GID from this range. If in > doubt, it is recommended to select successive numbers from 500 downwards. s/500/499/ > 2. Unless there is a very good reason not to, matching users and groups > should use the same number. It is acceptable to leave gaps in assignments > as a result of that. > > 3. Before pushing the new acct-* packages, the developer *must* push an > update to uid-gid.txt adding the 'acct' entry for the desired UID/GID. This > serves as a synchronization primitive to prevent collisions. > > Further UID/GID ranges will be open in the future as the need arises.
My mistake. Repaste with ->499: === All new user/group accounts must be created via GLEP 81 packages. The existing packages should be migrated on the next version bump or major update. CI system will remind developers to perform the migration. Existing and historical fixed UIDs/GIDs in range 0..499 (used in baselayout or via user.eclass) as listed in uid-gid.txt can be reused as-is in acct-* packages. UIDs and GIDs in range 0..100 are reserved for important system accounts. New assignments in that range need to be explicitly approved by the QA lead, in response to a justified request from the developer. The range 101..499 is provided for regular use by packages. The assignments from this range follow the following rules: 1. A developer can select an arbitrary free UID/GID from this range. If in doubt, it is recommended to select successive numbers from 499 downwards. 2. Unless there is a very good reason not to, matching users and groups should use the same number. It is acceptable to leave gaps in assignments as a result of that. 3. Before pushing the new acct-* packages, the developer *must* push an update to uid-gid.txt adding the 'acct' entry for the desired UID/GID. This serves as a synchronization primitive to prevent collisions. Further UID/GID ranges will be open in the future as the need arises. ===
(In reply to Michał Górny from comment #2) > The range 101..499 is provided for regular use by packages. The assignments > from this range follow the following rules: > > 1. A developer can select an arbitrary free UID/GID from this range. If in > doubt, it is recommended to select successive numbers from 499 downwards. Have you seen my comment from https://archives.gentoo.org/gentoo-dev/message/03a592fa4695bfa9075ec4b1e066d6b9 (the last part)? We should go upwards, not downwards.
(In reply to Thomas Deutschmann from comment #3) > Have you seen my comment from > https://archives.gentoo.org/gentoo-dev/message/ > 03a592fa4695bfa9075ec4b1e066d6b9 (the last part)? We should go upwards, not > downwards. No, I've stopped reading at the initial noise. Still, there are so many twists in that (last) part, I'm lost what is the exact reason you want to reverse practice already in use.
@qa, given no further comments, please vote on the policy as outlined in #c2.
(note that the policy won't start applying until Council approves GLEP 81 changes)
I vote yes.
I vote yes
Yes
I vote yes. [Had to re-read policies and threads first...]
Yes.
Yes. Unanimously approved. I've filed the request to approve GLEP update already (see 'See also').
