This is a systemic problem with many ebuilds that create user accounts. Let's take net-misc/tor, for instance: pkg_setup() { enewgroup tor enewuser tor -1 -1 /var/lib/tor tor } src_install() { ... fperms 750 /var/lib/tor fowners tor:tor /var/lib/tor ... } The part in src_install is useless, since pkg_setup results in (/usr/portage/eclass/user.eclass): if [[ ! -e ${ROOT}/${ehome} ]] ; then einfo " - Creating ${ehome} in ${ROOT}" mkdir -p "${ROOT}/${ehome}" chown "${euser}" "${ROOT}/${ehome}" chmod 755 "${ROOT}/${ehome}" fi and fperms/fowners has no effect during merge, since /var/lib/tor already exists as 755 tor:root. I see 3 possible solutions: supporting a switch to enewuser and passing the switch in each affected ebuild; fixing ebuilds by adding something like rmdir /var/lib/tor 2>/dev/null || : to pkg_setup (did that with my ebuilds); or fixing ebuilds by moving fperms/fowners to pkg_postinst as chown/chmod (problematic, since might revert user's customizations).
Mike Frysinger's November 23 message "restricting phases where enew{user,group} is allowed" <http://archives.gentoo.org/gentoo-dev/msg_ed43ed0df212ea26ef953fb061e9e860.xml> is relevant to this. The change he committed does not conflict with anything described in comment #0, but he does indicate that he would like to move away from using pkg_setup for user creation (unless the upstream build system requires the user to exist for compilation to work properly). If you are already auditing builds and/or rearranging their user management, pushing user creation down to pkg_preinst where possible would help with his long term plan. In the tor case described above, you could then have pkg_preinst handle everything related to /var/lib/tor: pkg_preinst() { [[ -e "${ROOT}/var/lib/tor" ]] local had_home=$? enewgroup tor enewuser tor -1 -1 /var/lib/tor tor if [[ "$had_home" -ne 0 ]]; then chgrp tor "${ROOT}/var/lib/tor" chmod 0750 "${ROOT}/var/lib/tor" fi }
*** This bug has been marked as a duplicate of bug 141619 ***
