On Feb 18, 2012, at 10:09 AM, Dan Ports wrote:
> On Sat, Feb 18, 2012 at 08:32:40AM -0800, James Berry wrote:
>> - The record of whether you've agree to the license is stored per-user
>> in ~/Library/Preferences/com.apple.dt.Xcode.plist:
> [...]
>> Maybe we need to create a macports user home at something like
>> /opt/local/users/macports, with no access except to
>> /opt/local/users/macportsLibrary/Preferences??? ?
>
> Well, there are already some ports that want to access the macports
> user's $HOME and run into problems because it's /var/empty. In
> https://trac.macports.org/ticket/31827 we were talking about creating a
> temporary, per-build home directory. If we're going to do that, which
> sounds like a good idea, we could populate it with that plist.
>
> Of course, we'd still have to get the user to accept the license once
> to generate that plist.
For now, in r89989, I've changed the home directory for the MacPorts user to
/opt/local/var/macports/home, and made this writable by root only, and given it
a preferences directory that the macports user can write to. These means the
user will be able to create an Xcode preference that sticks for the macports
user.
There are several things this change doesn't attempt to accomplish:
- It doesn't provide any particular special checking, prompting, or
help for the user to create this preference.
- It doesn't (pending further feedback) update the dmg installer to
fixup the setting for the macports home directory.
- I also didn't attempt to fix r31827 or even think much about that
case. If it is desired to create a per-build home directory,
then copying certain files into it from
/opt/local/var/macports/home/... and or the user's real home directory might
make sense.
I'm not convinced that using /opt/local/var/macports/home is any safer than
using /var/empty. Root can change files in either one. By using
/opt/local/var/macports/home, we at least isolate macport's damages to it, and
avoid having ports that might dirty /var/empty; we could also choose to clean
it of files we don't want.
James
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
