Ebuilds using the 'dobin' install function will fail if testing using an unprivileged user, with 'Operation not permitted' at the 'install' stage. I have tracked this down to https://github.com/gentoo/portage/blob/master/bin/ebuild-helpers/dobin#L24 Do we really need to set owner at this stage, surely it gets correctly assigned when you merge to the live system? All other binaries seem to be copied to the sandbox correctly as the unprivileged user. I appreciate this is somewhat an edge-case, as final ebuild will only be run as root, but it does generate a false error for testing purposes!
This already works with FEATURES=fakeroot. (In reply to Michael Everitt (IRC: veremit) from comment #0) > Do we really need to set owner at this stage, surely it gets correctly > assigned when you merge to the live system? We automatically map PORTAGE_USERNAME and PORTAGE_GRPNAME in the _post_src_install_uid_fix function, so we can safely substitute those when necessary. All other UIDs and GIDs are preserved when the files are merged to the live system.
This to me satisfactorily answers the issue of this bug. I'd suggest adding fakeroot to FEATURES in make.conf and close resolved ? WONTFIX since it is fixable but resolvable via an option already available.
Well, I like portage to be as tolerant as possible for cases like this. It's very close to how portage is often used in prefix environments (FEATURES=unprivileged is related). I think what we want it to do here is use PORTAGE_USERNAME and PORTAGE_GRPNAME when we don't have permission to use PORTAGE_INST_UID and PORTAGE_INST_GID. This can be handled on the python side, by dynamically modifying the PORTAGE_INST_UID and PORTAGE_INST_GID variables.
this looks like bug 566614 to me
(In reply to SpanKY from comment #4) > this looks like bug 566614 to me Well, the specific complaint about dobin in comment #0 is much smaller in scope than bug 566614. It's a relatively easy case to handle, and will work fine for a large subset of packages that don't require any special file permission settings.
Also applies to dosbin, for reference, but this is probably apparent to the portage team anyway, but adding for completeness.