1.9.2

[Rainer Müller]

On 2010-08-05 11:45 , Joshua Root wrote:
> On 2010-8-5 19:05 , Ryan Schmidt wrote:
>> 
>> On Aug 4, 2010, at 03:14, Joshua Root wrote:
>> 
>>> Does anyone have any more patches that should go into the 1.9.2
>>> release?
>> 
>> The change you made to fix 19935 seems to be drastic.
>> 
>> http://trac.macports.org/ticket/19935
>> 
>> It seems I can now no longer go to one window and type "sudo port
>> -u upgrade foo" and go to another window and type "sudo port -u
>> upgrade bar" and have both of them working at the same time. This
>> is a mode of working with MacPorts that I use almost every day.
> 
> Now you can do that with some confidence that one of them isn't going
> to fail. If you want to implement a more fine-grained (and
> considerably more complex) locking scheme to allow more concurrency,
> go ahead.

What Ryan describes is also something I am doing sometimes.

As I see it the problem is not about general modifications to the
registry, as sqlite is able to use locking for that itself.

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.

I don't think the solution for this is a general lock so only one port
instance can run.

Here is an previous log I produced that shows the problem:

Shell 1:

--->  Computing dependencies for ruby
--->  Fetching ruby
--->  Attempting to fetch ruby-1.8.7-p299.tar.bz2 from
http://lil.fr.distfiles.macports.org/ruby
--->  Verifying checksum(s) for ruby
--->  Extracting ruby
--->  Applying patches to ruby
--->  Configuring ruby
--->  Building ruby
[ now running command in Shell 2 ]
--->  Staging ruby into destroot
--->  Computing dependencies for ruby
--->  Installing ruby @1.8.7-p299_0+thread_hooks
--->  Deactivating ruby @1.8.7-p249_3+thread_hooks

Shell 2:

Waiting for lock on
/opt/local/var/macports/build/_Users_raim_src_macports_trunk_dports_lang_ruby/work/.macports.ruby.state
--->  Computing dependencies for ruby.
--->  Computing dependencies for ruby.
--->  Deactivating ruby @1.8.7-p249_3+thread_hooks


After Shell 1 finished with installation, the statefile lock is released
by closing the mport. Deactivation will then be run from the Portfile
stored in the registry. Therefore Shell 2 can acquire the lock and
begins to run on the same port. According to the still existing
statefile everything is in place already, so it skips to deactivation.
Now both port instances are trying to deactivate the same port.

So in my opinion the problem is that upgrade releases the lock on the
statefile too early before the version swap is finished. Either it needs
to keep that lock until after that is done or we need a per-port locking
mechanism for the registry.

Rainer