| 1 |
On Thu, 2019-06-20 at 09:07 -0400, Brian Evans wrote: |
| 2 |
> On 6/18/2019 7:31 AM, Michał Górny wrote: |
| 3 |
> > 3. Give people some time for wider testing. |
| 4 |
> > |
| 5 |
> > At this point, the new eclasses would be non-binding, i.e. you will |
| 6 |
> > still be able to commit new packages using user.eclass old style. |
| 7 |
> > The eclasses would be bound with usual eclass stability requirements, |
| 8 |
> > i.e. some API changes may happen if necessary. |
| 9 |
> > |
| 10 |
> > 4. If no major issues arise, submit GLEP 81 for formal approval. |
| 11 |
> > |
| 12 |
> > Once GLEP 81 is formally approved, using user.eclass directly becomes |
| 13 |
> > deprecated and new packages are expected to use acct-*/*. |
| 14 |
> > |
| 15 |
> |
| 16 |
> I object to this as some packages just need a user/group for a single |
| 17 |
> daemon that is not shared with another package. The numbering does not |
| 18 |
> really matter in this case as it will never leave the machine. |
| 19 |
> |
| 20 |
> user.eclass should exist for this purpose and the acct-{group/user} |
| 21 |
> should exist for static purposes which I find to be rather rare. |
| 22 |
> |
| 23 |
|
| 24 |
You should read the relevant discussion. The use cases for fixed |
| 25 |
UIDs/GIDs go beyond sharing users/groups. Most notably, they involve |
| 26 |
sharing filesystems, archives etc. I'm aware those things can't work |
| 27 |
reliably today but that's no reason to prevent users from trying to get |
| 28 |
them working in the future. |
| 29 |
|
| 30 |
|
| 31 |
-- |
| 32 |
Best regards, |
| 33 |
Michał Górny |
Archives