[MacPorts] #31827: MacPorts should make ${workpath}/home and set HOME to it (was: fetch.type bzr: permission issues due to incorrect ${HOME})
MacPorts
noreply at macports.org
Sun Oct 30 01:43:37 PDT 2011
#31827: MacPorts should make ${workpath}/home and set HOME to it
----------------------------------+-----------------------------------------
Reporter: ecronin@… | Owner: macports-tickets@…
Type: defect | Status: new
Priority: Normal | Milestone: MacPorts Future
Component: base | Version: 2.0.3
Keywords: | Port:
----------------------------------+-----------------------------------------
Changes (by ryandesign@…):
* cc: ryandesign@… (added)
* milestone: => MacPorts Future
Comment:
I'm aware there are several tickets now in which ports are forbidden by
MacPorts 2's privilege dropping code from writing and sometimes reading
items in the user's actual home directory; in these cases we have been
modifying the port to set HOME to something inside workpath.
I'm not sure why in some cases like #30289 it seems to know what the
macports user's home directory is, and in other cases it doesn't. As I
said I wasn't aware of MacPorts base actually setting HOME to anything at
this time. Perhaps it would be good for MacPorts base to create a
directory "${workpath}/home" for every port install and set HOME to that,
since that's what we already do manually in some ports (clisp (#31257),
parallel (r86242)).
Several ports have actually used this in-workpath HOME env var for a lot
longer than the privilege dropping code has existed (kmymoney (#24433),
the kde and koffice ports (r27011), plplot (r22893), scribus (r19058)) so
it may even be a good idea to standardize this for other reasons.
--
Ticket URL: <https://trac.macports.org/ticket/31827#comment:4>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list