with the previously proposed/accepted GLEP 27 stalled, i'm looking into
mitigating the current suckiness of enew{user,group}/egetent. the first step
is simple: let's split these funcs out of eutils.eclass and into a dedicated
eclass. this makes it trivial for people externally to override the
functionality and hook into whatever craziness they want.

eutils.eclass will inherit this new eclass directly (for the foreseeable
future), so there's no need for tree-wide update bonanzas.

suggested name: euser.eclass
-mike

On Thu, Oct 20, 2011 at 4:47 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> with the previously proposed/accepted GLEP 27 stalled, i'm looking into
> mitigating the current suckiness of enew{user,group}/egetent. the first step
> is simple: let's split these funcs out of eutils.eclass and into a dedicated
> eclass. this makes it trivial for people externally to override the
> functionality and hook into whatever craziness they want.

Wishlist item for the new eclass: a function that allows adding an
existing user (that had previously been created by enewuser) to a
particular group without dropping any other groups that the user is
already in. Would be very useful for gdm-3.2.

-Alexandre

On Thu, Oct 20, 2011 at 04:47:55PM -0400, Mike Frysinger wrote:
> with the previously proposed/accepted GLEP 27 stalled, i'm looking into
> mitigating the current suckiness of enew{user,group}/egetent. the first step
> is simple: let's split these funcs out of eutils.eclass and into a dedicated
> eclass. this makes it trivial for people externally to override the
> functionality and hook into whatever craziness they want.
>
> eutils.eclass will inherit this new eclass directly (for the foreseeable
> future), so there's no need for tree-wide update bonanzas.

Whatever the eclass name, the API it exports should be controlled
carefully so that when g27 lands, we can just swap the functionality
directly in- just have the eclass watch for a magic value

Either way, sounds good.
~brian

Mike, can you offer a tip on how to "trivially hook into whatever craziness" with the help of user.eclass? My goal is to have regular enewuser and enewgroup work for ROOT=/xyz. But I don't currently have a clue what would *not* be a horribly broken way to do this. It seems like I perhaps should write some additional code for handling ROOT into user.eclass and stick it in my overlay?

So after a reading through a bunch of stuff [1][2][3][4][5], what I'm going to do for the goal above is:

* move to sys-apps/shadow trunk [6]
* fork my own user.eclass from v1.17, modify it to use --root $ROOT when calling shadow stuff
* stick my user.eclass into myoverlay/eclass/
* # echo "lkraav" > myoverlay/profiles/repo_name
* # echo "[DEFAULT]
eclass-overrides = lkraav" > /etc/portage/repos.conf
* # echo "PORTAGE_RSYNC_EXTRA_OPTS="--exclude=/metadata/cache"" >> /etc/make.conf
* # rm -rf /usr/portage/metadata/cache
* # echo "emerge --regen" >> /etc/cron.weekly/09-my-portage-update-script
* subscribe to atom feed of portage user.eclass changes, merge stuff until sys-apps/shadow-4.1.4.5 surfaces and maybe main tree user.eclass gets patched to use --root
* try to achieve clamlike happiness with this setup

Anything particularly important I'm missing? Is this the rightish way to do it?

[1]: https://forums.gentoo.org/viewtopic-p-5877500.html
[2]: https://groups.google.com/forum/#!topic/linux.gentoo.dev/FYJ4g5IryIw/discussion
[3]: https://alioth.debian.org/tracker/index.php?func=detail&aid=312407&group_id=30580&at id=411480
[4]: https://bugs.gentoo.org/show_bug.cgi?id=53269'
[5]: http://www.linux-archive.org/gentoo-embedded/295178-emerge-root-users-not-created.html
[6]: https://bugs.gentoo.org/show_bug.cgi?id=393073

On 12/04/2011 09:44 AM, Leho Kraav wrote:
> So after a reading through a bunch of stuff [1][2][3][4][5], what I'm going to do for the goal above is:
>
> * move to sys-apps/shadow trunk [6]
> * fork my own user.eclass from v1.17, modify it to use --root $ROOT when calling shadow stuff

I think a possible problem here would be a build system that uses
user/group id's from the host root during the build process. If any
packages do this, it is possible that the users/groups would need to be
added in both /etc/passwd and ${ROOT}etc/passwd.

> * stick my user.eclass into myoverlay/eclass/
> * # echo "lkraav" > myoverlay/profiles/repo_name
> * # echo "[DEFAULT]
eclass-overrides = lkraav" > /etc/portage/repos.conf
> * # echo "PORTAGE_RSYNC_EXTRA_OPTS="--exclude=/metadata/cache"" >> /etc/make.conf
> * # rm -rf /usr/portage/metadata/cache
> * # echo "emerge --regen" >> /etc/cron.weekly/09-my-portage-update-script

That sounds about right.

> * subscribe to atom feed of portage user.eclass changes, merge stuff until sys-apps/shadow-4.1.4.5 surfaces and maybe main tree user.eclass gets patched to use --root

We have one of those!?

On 12/04/2011 06:44 AM, Leho Kraav wrote:
> So after a reading through a bunch of stuff [1][2][3][4][5], what I'm going to do for the goal above is:
>
> * move to sys-apps/shadow trunk [6]
> * fork my own user.eclass from v1.17, modify it to use --root $ROOT when calling shadow stuff
> * stick my user.eclass into myoverlay/eclass/
> * # echo "lkraav" > myoverlay/profiles/repo_name
> * # echo "[DEFAULT]
eclass-overrides = lkraav" > /etc/portage/repos.conf
> * # echo "PORTAGE_RSYNC_EXTRA_OPTS="--exclude=/metadata/cache"" >> /etc/make.conf
> * # rm -rf /usr/portage/metadata/cache
> * # echo "emerge --regen" >> /etc/cron.weekly/09-my-portage-update-script

If user.eclass is the only eclass you override, then since user.eclass
doesn't modify metadata variables like *DEPEND or IUSE, it's safe to use
metadata/cache from rsync.
--
Thanks,
Zac
ta

On Sunday, December 4, 2011 4:50:02 PM UTC+2, Leho Kraav wrote:
>
> * fork my own user.eclass from v1.17, modify it to use --root $ROOT when calling shadow stuff

So first thing I'm running into is replacing getent with something that supports chrooting. Only immediate thought for users is using passwd --status. For groups I'm not even seeing anything obvious to use.

Any thoughts?