Ports Accessing $HOME

Ryan Schmidt ryandesign at macports.org
Wed Aug 31 13:06:33 PDT 2011


On Aug 31, 2011, at 14:03, Jeremy Lavergne wrote:

> Do we consider ports that create and use a shared memory file in $HOME an
> mtree violation? This would be during the build and/or test phases [1].
> 
> How would we "properly" get around such a situation? Will that also
> account for a working mpab chroot (hopefully it'll work again, someday).
> 
> 1. https://trac.macports.org/ticket/30641

Well, an mtree violation is by definition a port that installs files to locations that are not specified in the mtree. But here we're talking about a port that merely creates a temporary file during the build, not something the port ultimately installs. So it's not an mtree violation. But it is definitely not allowed, at the moment, for a port to be attempting to create a file in $HOME, hence the error in the aforemetioned ticket. We had $HOME set to /dev/null on trunk before MacPorts 2.0.0 was released; we changed it to /var/empty so it was an actual directory, but nobody may write to this directory. There are plenty of ports that expect there to be a writeable home directory, and that's not an unreasonable assumption I think. Maybe MacPorts should create a temporary writeable directory (inside workpath?) before installing a port, let the port do whatever it wants with it, and clean it up afterward. MacPorts could even issue a warning or error if any files remain in this $HOME after the destroot phase runs; it could mean the port assumed it was helping the user set something up, which of course won't work, so this would be a good indication to the maintainer of something they need to manually handle in post-activate or via some explanatory notes.








More information about the macports-dev mailing list