I wanted to merge a larger amount of packages over night. I was kind of upset this morning when I noticed that emerge was canceled due to this message by the slocate ebuild: pkg_setup() { if [[ -n $(egetent group slocate) ]] ; then eerror "The 'slocate' group has been renamed to 'locate'." eerror "You seem to already have a 'slocate' group." eerror "Please rename it:" eerror "groupmod -n locate slocate" die "Change 'slocate' to 'locate'" fi enewgroup locate 245 } slocate was installed the first time on a fresh installation from the 2005.1 release. Instead of merging all packages I wanted, it stopped early here. The group "locate" did not exist on my system. So why not simply renaming that group by the ebuild and let the user know this by einfo? This is absolutely _no_ reason to stop emerge?! Reproducible: Always Steps to Reproduce: 1. emerge slocate # (the first time on newly installed system (2005.1)) Actual Results: Fails with error, stopping all eventually following merges. Expected Results: Should only inform and simply rename.
(In reply to comment #0) > So why not simply renaming that group by > the ebuild and let the user know this by einfo? Because any automated messing with existing groups is a bad idea(tm)? ;p
*** This bug has been marked as a duplicate of 12768 ***
IMHO, this is not exactly a dupplicate of #12768 . Of course, it could also be generally managed by portage, but I think it is not necessary to stop merging of slocate when the group instead could be renamed automatically ... So I think the ebuild needs to be adapted ... What specific reasons argue against automated group renaming? I mean, users and groups (e. g. for apache) are also automatically created ...
no ... src_install changes permissions of files using the groupname so if the group isnt renamed, src_install will fail to set proper permissions
