[gentoo-dev] User/group packages: the masterplan

[gentoo-dev] User/group packages: the masterplan

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

Hi, everyone.

Since there were no major objections raised against the proposal of
switching user/group management to dedicated acct-*/* packages, I'd like
to proceed as follows:

1. Commit GLEP 81 draft (as of last posting [1], plus patchset links
update).

2. Commit eclass change part of patchset v4 [2].

3. Give people some time for wider testing.

At this point, the new eclasses would be non-binding, i.e. you will
still be able to commit new packages using user.eclass old style.
The eclasses would be bound with usual eclass stability requirements,
i.e. some API changes may happen if necessary.

4. If no major issues arise, submit GLEP 81 for formal approval.

Once GLEP 81 is formally approved, using user.eclass directly becomes
deprecated and new packages are expected to use acct-*/*.

If anyone has any major objections against this, please voice them ASAP.

[1] https://archives.gentoo.org/gentoo-dev/message/2ca74142fa1d160f7573303d88b185b4
[2] https://archives.gentoo.org/gentoo-dev/message/527b343890c1280cb64efce2e941fdae

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] User/group packages: the masterplan

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

On Tue, 2019-06-18 at 13:31 +0200, Michał Górny wrote:
> Hi, everyone.
> 
> Since there were no major objections raised against the proposal of
> switching user/group management to dedicated acct-*/* packages, I'd like
> to proceed as follows:
> 
> 1. Commit GLEP 81 draft (as of last posting [1], plus patchset links
> update).
> 
> 2. Commit eclass change part of patchset v4 [2].

Pushed now.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] User/group packages: the masterplan

[Brian Evans]

[-- Attachment #1.1: Type: text/plain, Size: 937 bytes --]

On 6/18/2019 7:31 AM, Michał Górny wrote:
> 
> 3. Give people some time for wider testing.
> 
> At this point, the new eclasses would be non-binding, i.e. you will
> still be able to commit new packages using user.eclass old style.
> The eclasses would be bound with usual eclass stability requirements,
> i.e. some API changes may happen if necessary.
> 
> 4. If no major issues arise, submit GLEP 81 for formal approval.
> 
> Once GLEP 81 is formally approved, using user.eclass directly becomes
> deprecated and new packages are expected to use acct-*/*.
> 


I object to this as some packages just need a user/group for a single
daemon that is not shared with another package.  The numbering does not
really matter in this case as it will never leave the machine.

user.eclass should exist for this purpose and the acct-{group/user}
should exist for static purposes which I find to be rather rare.

Brian


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] User/group packages: the masterplan

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

On Thu, 2019-06-20 at 09:07 -0400, Brian Evans wrote:
> On 6/18/2019 7:31 AM, Michał Górny wrote:
> > 3. Give people some time for wider testing.
> > 
> > At this point, the new eclasses would be non-binding, i.e. you will
> > still be able to commit new packages using user.eclass old style.
> > The eclasses would be bound with usual eclass stability requirements,
> > i.e. some API changes may happen if necessary.
> > 
> > 4. If no major issues arise, submit GLEP 81 for formal approval.
> > 
> > Once GLEP 81 is formally approved, using user.eclass directly becomes
> > deprecated and new packages are expected to use acct-*/*.
> > 
> 
> I object to this as some packages just need a user/group for a single
> daemon that is not shared with another package.  The numbering does not
> really matter in this case as it will never leave the machine.
> 
> user.eclass should exist for this purpose and the acct-{group/user}
> should exist for static purposes which I find to be rather rare.
> 

You should read the relevant discussion.  The use cases for fixed
UIDs/GIDs go beyond sharing users/groups.  Most notably, they involve
sharing filesystems, archives etc.  I'm aware those things can't work
reliably today but that's no reason to prevent users from trying to get
them working in the future.


-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]