Currently affected packages: * evolution-data-server * gnome-extra/zeitgeist-datasources The reason for this is that python-single-r1.eclass calls python_wrapper_setup in pkg_setup which creates $T/pkgconfig as root:root with permission 0755. vala.eclass then tries to create a symlink in $T/pkgconfig in src_prepare phase which fails since src_prepare is run as portage or paludisbuild. Making $T/pkgconfig is a no-go since an unprivileged user may alter content there (because $T is most probably 0755).
hum I think doing stuff for build in pkg_setup is wrong and should be moved to src_prepare where it belongs.
(In reply to comment #1) I can agree with that. I guess I'm just a bit worried about our wrapper setup and env var export getting clobbered by ebuilds that define src_prepare without calling our function. I guess that's on the ebuild author, not us though. mgorny: Thoughts on if/how we should change this?
imho, the best we can do is respect phase definitions as much as we can, which is not exactly the case for vala eclass either and leave the ebuilds author with the responsability to use the eclasses properly.
(In reply to comment #2) > (In reply to comment #1) > > I can agree with that. I guess I'm just a bit worried about our wrapper > setup and env var export getting clobbered by ebuilds that define > src_prepare without calling our function. I guess that's on the ebuild > author, not us though. > > mgorny: Thoughts on if/how we should change this? That's one problem, and the other is that people may run things needing Python in pkg_* phases. And one more is that changing anything involving exported phases means tree-wide hell-of-a-breakage and is basically impossible. As a simplest solution, I think we can switch to using separate dirs for those created as root and with userpriv. Changing either is fine with me.
I went ahead and switched all the eclasses to consistently use ${T}/${EPYTHON} for the wrappers. This also fixes this issue.
