[90075] trunk/base/src/macports1.0/macports.tcl

[Clemens Lang]

On Wed, Feb 22, 2012 at 02:39:42AM +1100, Joshua Root wrote:
> Or go back to always copying (when possible). If we don't care whose
> plist it is though, we might as well just create one with the right
> keys to let us run and dispense with the copying.

If we just create a plist the user didn't accept the terms and
conditions, if we copy some plist on the box at least some user accepted
the terms; but you're right, it really should use the one created by the
user.

> The warning messages will be inaccurate some of the time though.

Yeah, that should probably be fixed. It's just a cosmetic issue, though.

> So why didn't I see any such errors? (I still don't if I remove the
> existence/mtime condition.) And wouldn't the problem remain in the
> case where the plist has been modified since it was copied?

I don't know why you're not seeing this, but it's very much reproducible
for me. Maybe it's related to the permissions of the target directory?

> And why did Dan set the ownership in the first place? I can see that
> making sense in the per-port dirs but not really in the global one.

I'm not sure, but I'm pretty sure the change that set the file
permissions is bogus:
	--w----r-T 1 macports admin 20K Feb 21 03:07 com.apple.dt.Xcode.plist
That should probably be file attributes -permissions 0644

Setting the ownership to the original owner of the file and changing
permissions to 644 might solve the problem, but then that will still
fail if more than one user uses macports, because user B won't be able
to overwrite user A's plist file in this directory.
I think the only clean solution would be to only copy the file if
running with elevated privileges, or when in a non-root install of
MacPorts.

-- 
Clemens Lang
GSoC Student