Functions enewuser and enewgroup of eclass eutils adds the new users and groups to the /etc/passwd and /etc/group of the host/build machine, regardless of $ROOT. If using $ROOT to specify a target system to build, the expected behaviour would be to modify $ROOT/etc/passwd and $ROOT/etc/group. Reproducible: Always Steps to Reproduce: 1. Set ROOT variable to a target system, other than / 2. Install a package that uses enewuser or enewgroup (apache, trac, openssh, dhcp...) Actual Results: /etc/passwd, /etc/shadow and /etc/group are modified with the new users/groups, $ROOT/etc/passwd, $ROOT/etc/shadow and $ROOT/etc/group are untouched. Expected Results: /etc/{passwd,shadow,group} left untouched, $ROOT/etc/{passwd,shadow,group} modified with the new users/groups added. Proposed fix: enewuser and enewgroup defers user and group creation to useradd and groupadd. chroot to $ROOT when calling these programs.
Ebuild developers should take care to only add these users/groups to the build host when the build system (configure/compile/install phases) fail without them, and equally that the users/groups are added to the target system too. For the first purpose we have the pkg_setup() phase. The pkg_preinst() and pkg_postinst phases are there to introduce new users/groups to the target system. However, there is nothing wrong with the concepts of enewuser and enewgroup themselves - what you could provide instead are examples of where the use of these functions goes wrong, and file separate bugs for separate cat-egory/pkg's.
(In reply to comment #1) You are right about making the distinction between the build-time and run-time, where new users/groups need to be added to the build system and to the target system, respectively. Yet, even compliant ebuilds (eg. net-misc/dhcp/dhcp-3.1.2_p1.ebuild) where enewuser/enewgroup are used in an install function (pkg_preinst in the case of dhcp) do not work properly. The group and user 'dhcp' get added on the build system. That is understandable and expected from the code of enew{user,group} since it doesn't check for the $EBUILD_PHASE if it is setup or preinst or postinst, and it just calls useradd and groupadd without any reference to $ROOT. btw, it checks if $EBUILD_PHASE is unpack|compile|test|install but not prepare which is a sandboxed function too, isn't that a mistake? Proposed fix: replace useradd (groupadd) with a wrapper that would check $EBUILD_PHASE and run useradd (groupadd) directly if it is setup, and run chroot $ROOT useradd (groupadd) if it is preinst or postinst.
*** This bug has been marked as a duplicate of bug 266246 ***
