On 01/28/2011 06:26 AM, Donnie Berkholz wrote: > On 11:55 Thu 27 Jan , Zac Medico wrote: >> On 01/27/2011 11:08 AM, Matthew Summers wrote: >>> One question though. Since the 'portage' user has its $home set by default >>> to /var/tmp/portage how would you recommend handling the ssh key situation >>> since that directory is somewhat special? >> >> Well, I've never tried it, so I don't have any recommendation atm other >> than to make sure FEATURES=userpriv is not enabled. >> >> Moving forward, maybe it would make sense to have a notion of a >> configurable "fetcher home" that package managers and live/vcs eclasses >> would use for the HOME variable only when fetching. For example, the >> user could configure this by setting a FETCHER_HOME variable. > > This might be useful in other scenarios besides fetching that just > haven't occurred to us yet. Perhaps we should treat the portage user as > a regular user with a regular home directory that can be configured as > desired, and flip in and out of that user on demand.
Well, the problem that I see with having a common $HOME for execution of _all_ ebuilds is that it will be likely to accumulate all sorts of junk from the various programs that are executed by ebuilds, and this can lead to all sorts of bugs that may or may not be reproducible based on the state of this directory on a given user's system. Currently, portage always sets $HOME to a private temporary directory which is a sibling of other private temporary directories such as $WORKDIR, $T, and $D. This has the advantage of providing a clean slate for each ebuild, ensuring reproducible results and no accumulation of junk. This is why I suggested that we used a separate $HOME that is only for fetching purposes, in order to minimize the risk of junk accumulation and resulting problems with reproducibility. -- Thanks, Zac
