exeopts essentially sets parameters supplied to the `install` command. This command fails when it cannot set the requested permissions. Considering that the prefixed portage is stripping out many filesystem-ownership and account-creation operation, I assumed the proper way to fix it is to strip of "-o" and "-g" from install. I didn't manage to make it a bash regular expression (=~) and used `sed` instead. Sorry for this.
I seem unable to attach any more files to any open bugs. Will do it tomorrow. :(
Created attachment 241921 [details, diff] Patch against prefixed portage to filter out -o and -g in exeopts
Created attachment 241923 [details, diff] The actual patch needed.
(In reply to comment #0) > exeopts essentially sets parameters supplied to the `install` command. This > command fails when it cannot set the requested permissions. Considering that > the prefixed portage is stripping out many filesystem-ownership and > account-creation operation, I assumed the proper way to fix it is to strip of > "-o" and "-g" from install. Well, I disagree there. Even though the most common use case is for non-root users, we actually try to support root users too. With that said, I don't know of a proper fix at the moment.
Created attachment 248444 [details, diff] Updated patch to strip -o and -g from install only when on prefixed portage What about this? EPREFIX should be empty for mainline portage. This applies the change only when $EPREFIX is not present. We could additionally only apply it if [ `uid -u` -ne 0 ], but the rest of the prefixed portage is also not that sophisticated.
(In reply to comment #5) > `uid -u` I meant `id -u`.
There's two packages that use this: sys-apps/pmount www-apps/webdavcgi In the current state of the tree, it seems it's better to fix the two packages (if there is a need) than changing Portagr for it.
