| 1 |
On Sun, Nov 28, 2021 at 3:26 PM William Hubbs <williamh@g.o> wrote: |
| 2 |
> |
| 3 |
> On Sun, Nov 28, 2021 at 02:57:39PM -0500, Michael Orlitzky wrote: |
| 4 |
> > On 2021-11-28 11:06:36, Ulrich Mueller wrote: |
| 5 |
> > > |
| 6 |
> > > While the rationale for static allocation that made it into GLEP 81 [1] |
| 7 |
> > > is rather weak, several people had argued in favour of it on the mailing |
| 8 |
> > > list [2]. |
| 9 |
> > > |
| 10 |
> > |
| 11 |
> > We don't even do static allocation. The UIDs and GIDs in the ebuilds |
| 12 |
> > are suggestions, meant to benefit the people who will benefit from |
| 13 |
> > them, and be ignored by everyone else. |
| 14 |
> > |
| 15 |
> > There are a few exceptional cases where a user or group needs a |
| 16 |
> > specific identifier; but those were always statically allocated and |
| 17 |
> > nothing has changed in that regard. |
| 18 |
> |
| 19 |
> Doesn't the emerge fail if a different user with ACCT_USER_ID already exists on |
| 20 |
> the system (unless ACCT_USER_ID is set to -1, which is forbidden by qa policy)? |
| 21 |
|
| 22 |
Not by default. If the eclass finds that ACCT_USER_ID is already |
| 23 |
taken, it will allow useradd to assign a different one. |
| 24 |
|
| 25 |
This behavior can be overridden by ebuilds (or a user) by setting |
| 26 |
ACCT_USER_ENFORCE_ID. |
Archives