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 $HO ME 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. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
