On Tue, 2022-12-06 at 18:54 -0500, Mike Gilbert wrote:
> On Tue, Dec 6, 2022 at 5:24 PM James Le Cuirot <ch...@gentoo.org> wrote:
> >
> > Groups are largely irrelevant for prefix, but we still don't want the
> > build to break.
> >
> > Signed-off-by: James Le Cuirot <ch...@gentoo.org>
> > ---
> > eclass/acct-group.eclass | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
> > index 590a2f20ed8e..ada5fe386693 100644
> > --- a/eclass/acct-group.eclass
> > +++ b/eclass/acct-group.eclass
> > @@ -176,7 +176,7 @@ acct-group_pkg_preinst() {
> > fi
> >
> > if [[ -n ${ROOT} ]]; then
>
> You should probably change this to [[ -n ${EROOT} ]]. Same goes for
> acct-user.eclass.
>
> Also see bug 779181; I'm not sure updating ${EROOT}/etc/group and
> ${EROOT}/etc/passwd makes any sense at all.
Hmm. On closer inspection, and after seeing that bug, I realise I have made
some bad assumptions.
I glanced at my old prefix and saw a bunch of additional users and groups in
there, so I figured the tools must have automatically operated on
${EPREFIX}/etc. In fact, user.eclass skipped the operation if you were root,
and these files were merely copies from /etc. I tried groupadd from a prefix,
and it defaulted to /etc.
The new eclasses also skip the operation if you are root. As that bug report
says, running a prefixed system as root is probably unsupported. I was doing
this as root into a ROOTed prefix though, which is slightly different. Should
we also skip the operation if EPREFIX non-empty? I'll think about it.
Thanks for pointing this out.
signature.asc
Description: This is a digitally signed message part
