1.9.2

[Rainer Müller]

On 2010-08-05 16:25 , Joshua Root wrote:
> On 2010-8-5 23:24 , Rainer Müller wrote:
>> The problem with activate/deactivate was introduced by the fact that
>> activation/deactivation is now being run from the registry Portfile
>> making the statefile lock ineffective for another instance working on
>> the Portfile in the tree.
> 
> That may have made the problem more noticeable in some situations, but
> it didn't cause it.

Hm, in which other situation would macports first check the current
state and act later?

And in which case can such a thing happen while changing requested
ports, which you added to the actions requiring locking?

>> I don't think the solution for this is a general lock so only one port
>> instance can run.
> 
> It's the only simple, correct solution that I can see.

Okay, if this is what we are going to use now it's implementation is not
correct at the moment. It is now locking in the port command line client
and is likely to cause the same problem again when using another client
in parallel, e.g. MacPorts Framework for GUI. So this should at least be
moved to the macports package instead as it is clearly not a issue with
the command line client only.

Rainer