While this does seem to be a feature, the problem is that if you have to change user details (ie. group membership), it just returns without changing the details. Reproducible: Always Steps to Reproduce: 1. Ebuild XXX-0.1: enewuser foo -1 /bin/false /dev/null foo 2. emerge XXX 3. user foo is in group foo 4. Ebuild XXX-0.1: enewuser foo -1 /bin/false /dev/null foo,bar 5. emerge XXX 6. user foo is in group foo (but not bar) Actual Results: user data is not modified Expected Results: If the user exists, the user should be removed and then recreated with the new information. This is particularly important when (for instance) a later version of a daemon drops priviledges (where the previous version didn't). For the later version, if an upgrade occurs it may need to give the user special priviledges. This is the exact problem that we are experiencing with upgrading hal to 0.5.1 in the tree.
your cut is broken
nope. The code is this: # lets see if the username already exists if [ "${euser}" == "`egetent passwd \"${euser}\" | cut -d: -f1`" ] then return 0 fi einfo "Adding user '${euser}' to your system ..." If the user already exists, it exits by design. I'm saying that this api is problematic. In reality, it should be: # lets see if the username already exists if [ "${euser}" == "`egetent passwd \"${euser}\" | cut -d: -f1`" ] then userdel "${euser}" fi einfo "Adding user '${euser}' to your system ..."
no, userdel should not be called, that's bad design enewuser is to create a new user, and that's it what you want is (by design) not happening
Then what API is an ebuild suppossed to use to modify a user (if it exists) or add one if it doesn't?
no api exists (nor do i think one should be added) because you shouldnt be modifying users
hal creates the user haldaemon. this user isn't in any groups (other than haldaemon) because it keeps priviledges. The new version changes this, dropping priviledges. Thus, the new hal will be *broken* if the user haldaemon is not in the disk and cdrom groups (which it isn't in previous installs). So for people upgrading, we have a few choices: 1. modify the user 2. create a new (different) user with the proper priviledges, leaving the old user 3. bail and force users to remove the haldaemon user before installing #2 is sloppy. #3 is sloppy. #1 is the only real answer.
that's fine, add whatever hacks you want to your packages, but it doesnt make sense in global API the reason enewuser just checks for the existence of the user is so that admins can create the users with whatever tweaks they want (home/uid/whatever) if enewuser just reset that everytime, that'd be bad
I can live with that...
