While not strictly covered by PMS, most of the PMs have some kind of userpriv. As a result, pkg_* phases are done with root privileges and src_* phases with some kind of pre-defined build user. However, this user is inconsistent between PMs and there's no good way of obtaining it. As a result, there's no clear way for pkg_setup() to create files that will be clearly readable & writable by the remaining phases. Please either: 1. guarantee that any files created during pkg_setup will be owned by the user used for build (or have equivalent permissions), 2. provide us a way to obtain the user that will be used for build, so we could chown them ourselves.
(In reply to Michał Górny from comment #0) > 2. provide us a way to obtain the user that will be used for build, so we > could chown them ourselves. http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commitdiff;h=4b22701aa7733e53778fc4d456819fc010e198b0
It feels like you're trying to do something icky here. What's the use case, and how does it interact with binary packages?
(In reply to Ciaran McCreesh from comment #2) > It feels like you're trying to do something icky here. What's the use case, > and how does it interact with binary packages? The use case is preparing Python wrappers. It may be done in pkg_setup(), and then the same wrapper can be reused for remaining phases. Since pkg_setup is called both for binary & source installs, the wrappers are created in both cases the same way.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #1) > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commitdiff; > h=4b22701aa7733e53778fc4d456819fc010e198b0 Interesting. Apropos and OT, surely @@ -1488,0 +1489,1 @@ def spawn(mystring, mysettings, debug=0, free=0, droppriv=0, sesandbox=0, fakero + "umask": 0o02 is a typo?
(In reply to Jouni Kosonen from comment #4) Where do you see a typo?
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #5) > Where do you see a typo? Sorry, braino. Of course the group write bit is on when the group is set.
(In reply to Michał Górny from comment #0) > 1. guarantee that any files created during pkg_setup will be owned by the > user used for build (or have equivalent permissions), I still don't understand the use case. _Where_ would pkg_setup possibly create such files? WORKDIR and D are not valid in pkg_setup, and I assume that you don't want to write to the live system. That would leave only HOME and T.
(In reply to Ulrich Müller from comment #7) > (In reply to Michał Górny from comment #0) > > 1. guarantee that any files created during pkg_setup will be owned by the > > user used for build (or have equivalent permissions), > > I still don't understand the use case. _Where_ would pkg_setup possibly > create such files? WORKDIR and D are not valid in pkg_setup, and I assume > that you don't want to write to the live system. That would leave only HOME > and T. ${T}/_${EPYTHON}, to be more precise.
Would a couple of variables like BUILD_USER and BUILD_GROUP be enough? Or a single variable BUILD_USER containing "user:group"?
(In reply to Ulrich Müller from comment #9) > Would a couple of variables like BUILD_USER and BUILD_GROUP be enough? Or a > single variable BUILD_USER containing "user:group"? Either will work for me.