[gentoo-dev] RFC: Userkit.eclass

[Manuel Rüger]

Hi everyone,

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.

It will also be possible to enable a switch to that makes the ebuild
fail if those are not set, as you then can set those variables first.
Another one allows to make them nops (which is nice for testing the
ebuild via "ebuild $PN test").

My only concerns right now are:
Where to store those ${CATEGORY}-${PN}_user and ${CATEGORY}-${PN}_group?
One solution could be to have another eclass named userkit-data.eclass,
which is empty by default and needs to be forked to an overlay and then
use the eclass-override setting in repos.conf. Unfortunately this will
cause a lot of md5-cache rewrites.
Another solution would be portage/package.env or portage/env.

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.

Any thoughts?

Cheers,

Manuel