If the nx group is already present, the install crashes. I had to remove that group before. Reproducible: Always Steps to Reproduce: emerge nxserver-freenx Actual Results: ebuild installation dies nxserver-freenx-0.7.1 is also affected
Post the errors you get and reopen then.
useradd : le groupe nx existe - si vous voulez ajouter cet utilisateur à ce groupe, utilisez -g. * * ERROR: net-misc/nxserver-freenx-0.7.1 failed. * Call stack: * ebuild.sh, line 1717: Called dyn_setup * ebuild.sh, line 768: Called qa_call 'pkg_setup' * ebuild.sh, line 44: Called pkg_setup * nxserver-freenx-0.7.1.ebuild, line 42: Called enewuser 'nx' '-1' '-1' '/var/lib/nxserver/home' * eutils.eclass, line 583: Called die * The specific snippet of code: * useradd ${opts} ${euser} \ * -c "added by portage for ${PN}" \ * || die "enewuser failed" * The die message: * enewuser failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/net-misc/nxserver-freenx-0.7.1/temp/build.log'. * * Messages for package net-misc/nxserver-freenx-0.7.1: * * ERROR: net-misc/nxserver-freenx-0.7.1 failed. * Call stack: * ebuild.sh, line 1717: Called dyn_setup * ebuild.sh, line 768: Called qa_call 'pkg_setup' * ebuild.sh, line 44: Called pkg_setup * nxserver-freenx-0.7.1.ebuild, line 42: Called enewuser 'nx' '-1' '-1' '/var/lib/nxserver/home' * eutils.eclass, line 583: Called die * The specific snippet of code: * useradd ${opts} ${euser} \ * -c "added by portage for ${PN}" \ * || die "enewuser failed" * The die message: * enewuser failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/net-misc/nxserver-freenx-0.7.1/temp/build.log'. *
If the nx group is present and the nx user is not, it doesn't install. If both are there or none are there it works.
Set your locales to C when reporting bugs, please. <snip> useradd: group nx exists - if you want to add this user to that group, use -g. </snip> Well, I find this sys-apps/shadow feature highly annoying because it plain doesn't make sense. The only way to prevent this is to *always* specify at least one group in enewuser call, which may be unwanted and doesn't match eutils.eclass documentation.
(In reply to comment #4) > Set your locales to C when reporting bugs, please. > > <snip> > useradd: group nx exists - if you want to add this user to that group, > use -g. > </snip> > > Well, I find this sys-apps/shadow feature highly annoying because it plain > doesn't make sense. The only way to prevent this is to *always* specify at > least one group in enewuser call, which may be unwanted and doesn't match > eutils.eclass documentation. > What could be done is to ask the user what to do in such situation. Something like "The group nx is already present, to proceed with the of the install it must be delete. Say yes or no" I will experiment with that and report here later.
(In reply to comment #5) > What could be done is to ask the user what to do in such situation. Something > like "The group nx is already present, to proceed with the of the install it > must be delete. Say yes or no" ebuilds are non-interactive by design, so... that really doesn't solve the issue at hand. The problem is that useradd by default tries to add a group with the same name if you don't specify any, and fails in this way if it already exists for no good reason. The behaviour is apparently buggy: <snip> -g The group name or number of the user's initial login group. The group name must exist. A group number must refer to an already existing group. The default group number is 1 or whatever is specified in /etc/default/useradd. </snip> Well, `useradd test` completely ignores the default GROUP=100 and creates group test as well. `useradd test -g` fails with 'option requires an argument'.
(In reply to comment #6) Well, in that case it would be good to provide an error message that describes the problem more clearly by providing the necessary steps to the user.
(In reply to comment #6) > The problem is that useradd by default tries to add a group with the same name > if you don't specify any, and fails in this way if it already exists for no > good reason. The behaviour is apparently buggy: No, the design was very intentional. The UNIX security model transitioned from default "everyone can read my files" to a more sane and restrictive "only I can read my files". The useradd feature was implemented almost 20 years ago in order to facilitate users having better control over their files. The reason it barfs when creating a user which has the same name as an existing group is to prevent an accidental exposure of the former user's files to the new user's files. If user "bob" assigns all of their files to group "bob", some other "bob" shouldn't then be allowed to see the former "bob" group files without the administrator making a conscious decision to allow that. If a hardwired user and group name is required for a product, the product developer should have the sense to code the installation scripts to account for this scenario. The bug is in the package that is using "useradd", not in the "useradd" command itself.
