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

[Joshua Root]

On 2012-2-22 01:01 , Clemens Lang wrote:
> On Wed, Feb 22, 2012 at 12:22:46AM +1100, Joshua Root wrote:
>> What if the user running port is not the user who ran it last time?
> 
> MacPorts might be getting the wrong Xcode.plist then, but is this really
> an issue? To fix this we would have to store where we copied the plist
> from.

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.

>> Also, the procedure you edited doesn't just handle temporary per-port
>> home dirs, it also does /opt/local/var/macports/home.
> 
> And that should be working just fine, since the procedure should detect
> that the file doesn't exist in the temporary home and copy it.

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

>> What errors were you seeing? What does the macports user have to do
>> with running without sudo?
> 
> The problem occurs when running port with sudo, which copies the file
> from the user's home and chowns it to the macports user. The next time
> the user runs port without sudo the procedure will attempt to copy the
> file again, but fails to do so, because it can not overwrite the now
> macports-owned copy. Since we did this unconditionally this always
> failed when invoking port without sudo and caused error messages in
> every command and also bash-completion, which calls port internally.

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?

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.

- Josh