1 |
On 23.11.2016 10:08, Michał Górny wrote: |
2 |
> On Wed, 23 Nov 2016 09:44:33 +0100 |
3 |
> Manuel Rüger <mrueg@g.o> wrote: |
4 |
> |
5 |
>> I have not started to write it, but I am considering it and rather want |
6 |
>> to gather feedback on my idea first. |
7 |
>> I am aware that https://wiki.gentoo.org/wiki/GLEP:27 exists, but as of |
8 |
>> right now I haven't seen anyone working on it. The goal of this eclass |
9 |
>> is to improve user/group handling without touching the PMS. |
10 |
>> |
11 |
>> tl;dr: Userkit eclass will improve the user handling by externalizing |
12 |
>> the configuration to variables that can be set from outside of the ebuild. |
13 |
>> |
14 |
>> Userkit.eclass will inherit user.eclass and require bash arrays |
15 |
>> USERKIT_USER and USERKIT_GROUP for configuration. |
16 |
>> I will export a pkg_setup with the corresponding setup (basically |
17 |
>> calling enewuser and enewgroup). It will provide get_user, get_uid, |
18 |
>> get_group, get_gid and get_home functions. |
19 |
>> This would allow to do something like "fowners $(get_user):$(get_group) |
20 |
>> foo". |
21 |
>> |
22 |
>> If ${CATEGORY}-${PN}_user and ${CATEGORY}-${PN}_group are set, these |
23 |
>> will replace the contents of USERKIT_USER and USERKIT_GROUP, allowing |
24 |
>> the user to fully define everything user/group related. |
25 |
> |
26 |
> How does that all map to multiple users/groups? How does that map to |
27 |
> USE-conditional users/groups? How does that map to users/groups shared |
28 |
> between multiple packages? |
29 |
> |
30 |
simply via calling the function conditional in pkg_setup |
31 |
My goal is not to focus on handling multiple users/groups. Synchronizing |
32 |
settings between multiple packages is a task of the user, it doesn't |
33 |
make any sense to make guesses there. People will come up with wonderful |
34 |
symlinked solutions. |
35 |
> Besides, this sounds a lot like games.eclass... will developers be |
36 |
> required to patch upstream software now to force support for using |
37 |
> custom users/groups? |
38 |
I am not aware of any patches that are required. What I care about is |
39 |
having predictable uid/gid and home for everything I can configure via |
40 |
an ebuild. |
41 |
|
42 |
> |
43 |
>> What happens if the ebuild wants to create multiple users/group? |
44 |
>> Currently, I want to ignore that case and focus on the 80% ebuilds that |
45 |
>> can profit from such an eclass. |
46 |
> |
47 |
> Do you have specific numbers? I don't see 80% of ebuilds caring about |
48 |
> users/groups. I don't see the problem you are trying to fix. |
49 |
> |
50 |
Okay let me rephrase that here: "probably more than 80% of the ebuilds |
51 |
that are calling enewuser/enewgroup" install a single user or a single |
52 |
group. There will be some cases this eclass is not applicable to, but |
53 |
that is fine. If this is something we really want to coveras well using |
54 |
the eclass based approach, we probably could start enumerating the |
55 |
variable and if those available to what needs to be done. Something like |
56 |
USERKIT_USER_2. Not sure if we want to do that. |
57 |
|
58 |
> Is it one of those problems that someone thinks it's awesome to make |
59 |
> everything declaratory, and add tons of middleware to make the |
60 |
> declaratory work somehow for the most common use cases? |
61 |
> |
62 |
I don't see "tons of middleware" here. |