if using fowners with wildcards like fowners nobody:nobody /my/dir/* the "*" expansion is performed on the real "/" (ignoring ${D}). Reproducible: Always Steps to Reproduce: Actual Results: fowners call to chown fails with "no such file or directory" Expected Results: should set the ownership and handle $D correctly FIX: in /usr/lib/portage/bin/fowners change ^for.* to for FILE in ${D}$*; do
addition to the fix: ${D} has to be removed from the chown-line of course.
I figured out that my fix-suggestion was not complete: it only works for _one_ file-parameter. One solution would be to test for _exactly 2_ parameters in fowners. Maybe disabling filename-expansion temporarily with "set -f" offers an other solution (with 2 nested loops)?
Any progress or feedback on this?
Created attachment 29141 [details] fowners hacked finally the activation energy was high enough to dig into this a bit deeper ... note: To realize it in pure bash (no fork) 2 temporary vars are needed (the names choosen are rather long to be self-expanatory). Filenames with spaces are handled correctly. The "ERROR"-message should be removed later on as fowners should be used like fowners user:group f1 f2 d1/f3 || die in ebuilds. If this version is going to make it into portage: fperms should be modified the same way.
*grr* correction: it should read: filenames with spaces are NOT handled correctly. I think that is a minor problem (nevertheless a problem).
eval is bad. You can't really fix globs like that without a lot of work. Best solution is to not add ${D} if it's already there.
Handling wildcards isn't going to happen. That's a bash thing. They're expanded before fowners is even called. Ebuild writers just have to be smarter than that. For the other stuff, see bug 97324
