Summary: | user.eclass: enewuser/group doesn't honor ROOT environment variable | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jaco Kroon <jaco> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | kevin |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jaco Kroon
2012-04-23 08:12:14 UTC
Actually, turns out this may be an issue with the user eclass. Can't see if there is an easy fix though ... perhaps using chroot "${ROOT}" getent (for example) ... but can one rely on getent always functioning within the chroot? What about the case where the user needs to also exist during compile/install phase and not only during runtime? Bug 53269, comment #49 suggests that shadow's new --root option might help. Indeed, that looks useful! Negates the need for having shadow merged inside the ROOT environment (even though in all probability it is very likely to be merged already). Perhaps a two-stage fix (and I think based on the info I might be willing to attempt a patch now): 1. Check if the non-ROOT env has a shadow supporting --root, if it has, use it. 2. If the above fails, try chroot "${ROOT}" useradd ... hack ... If that fails, enew{user,group} fails. If anybody can give me go-ahead in principle, I'll see what I can do re cooking up a patch implementing the above. |