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