The postfix-2.0.11.ebuild file is greping /etc files and this IS NOT the way to check for a user to install packages due to the fact that someone might be doing this on NIS or other types of authentication. This completely breaks the build process for anyone that is using something more sofisticated than /etc/passwd. It makes more sense to grep on the output of groups USERNAME to determine if the user is valid AND is in the proper group regardless of the results of trying to add a user/group to the files. (which should work for anything that pam can swallow) I cludged my own script to check for /etc/yp.conf (any NIS machine will have it) and ignore the checks/additions in the script, which will work for my use. But, it really needs to be fixed. This likely effects later ebuilds as well, but I haven't personally checked. - Sean
if ! grep -q ^postdrop: /etc/group ; then groupadd postdrop || die "problem adding group postdrop" fi if ! grep -q ^mail:.*postfix /etc/group ; then usermod -G mail postfix || die "problem adding user postfix to group mail" fi I assume this is the block of code you are talking about. Regardless of the authentication users utilize to connect to the server, the method being used to modify the files in /etc follows a proper procedure. Any running postfix service is going to require a local "postfix" user account and group and the user belonging to the mail group. So you are saying that on your system you do not have an /etc/group?
Yes, that looks like the right code block there. I have an /etc/group.. it however contains only +::: (so NIS maps will be used). Running portage as root e.g. "emerge postfix" will attempt add accounts to local files, which is ok. It will actually FAIL to add these accounts because NIS master has them already. It seems to be mishandling the error code from groupadd/useradd when a user already exists. It's a failure, but not a failure that should stop the build. I can run the bit without the "|| die" on the command line and it will work fine, it reports that "group postdrop already exists" which is correct. The ebuild is likely mishandling the return code, as I said previously. Unfortunately, I don't know enough about ebuilds to help you much further. But, I try. :) - Sean
postfix has upgrades on a regular basis. With the next release I will have the "die" portion removed as it works for your system and really is just a secondary protective measure.
I have removed the || die portions from the postfix-2.0.13-r1.ebuild please let me know if you have any further problems or if things appear to work correctly for you.
