On 11/23/2016 01:08 AM, 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? > > 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? > >> 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. > > 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 think the use-case here is ebuilds that need to create a user and/or group (www-servers/lighttpd is a good example; alongside pretty much anything else that needs to run as a separate user and serves something). In lighttpd's case we don't currently support the ability to declare which user and group lightty uses; the lighttpd user and lighttpd group will always be created. Later configuration of users and groups can be worked with, and iirc we recently patched the initscript so it handles that use case.
I could see a use-case for someone wanting to install a given daemon or server with a specific user and/or group. I'm not sure this is the right approach (nor do I know what is), but I think we have room to think about a solution; ideally one that is dead-simple to implement and doesn't have a ton of edge-cases. What is QA's current policy on user/group creation, btw? -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
