Indeed��� this has to do something with caching: when looking a .mcz the system just takes the one it finds, which might be
one with the same name but different.

Maybe we could for real put (part of) the UID in the filename?

In a disconnected system the case that the filename is the same for different files will always happen if the name is contructed
as it is now.

�� �� �� �� Marcus

> On 02 Jun 2015, at 22:37, stepharo <stepharo@free.fr> wrote:
>
> I hate so much this bug....
>
>
> Le 1/6/15 15:04, Ben Coman a ��crit :
>> Stef, I can now see all the dependent packages for the new slice, but
>> I still have a strange error.�� However I'm not sure if its a bug or
>> something unique at my end.
>>
>> Can someone try merging
>> SLICE-Issue-15646-Cleaning-method-category-api-should-be-protocol-part-1-StephaneDucasse.1
>>
>> What I see at top of stack is two calls to MCVersionMerger>>addVersion:
>>
>>�� �� ��MCVersionMerger>>addVersion: aVersion
>>�� �� �� �� ��records add: (MCMergeRecord version: aVersion).
>>�� �� �� �� ��aVersion dependencies
>>�� �� �� �� �� �� ��do: [:ea | | dep satisfied |
>>�� �� �� �� �� �� �� �� ��dep := ea resolve.
>>�� �� �� �� �� �� �� �� ��satisfied := (records anySatisfy: [:r | r version = dep]).
>>�� �� �� �� �� �� �� �� ��satisfied ifFalse: [self addVersion: dep]]�� "<<< race? "
>>�� �� �� �� �� �� ��displayingProgress: [ :ea| 'Searching dependency: ', ea
>> package name]
>>�� �� ��"15646Note: variable /satisfied/ added for reporting/debugging"
>>
>> One level down from where the error occurs the debugger shows...
>>
>>�� �� ��/aVersion/ --> a
>> MCVersion(SLICE-Issue-15646-Cleaning-method-category-api-should-be-protocol-part-1-StephaneDucasse.1)
>>
>>�� �� ��/ea/ --> a MCVersionInfo(DebuggerActions-StephaneDucasse.75)
>>
>>�� �� ��/dep/ --> nil
>>
>>�� �� ��/satisfied/�� --> false
>>
>> and the following which contradicts the value in /satisfied/
>>
>>�� �� ��(records anySatisfy: [:r | r version = dep]) --> true.
>>
>> so there seems to be a race such that the ifFalse block is improperly
>> executed, such that the recursive call on top of stack has...
>>
>>�� �� ��/aVersion/-->nil
>>
>> hence MNU receiver of "dependencies" is nil.
>>
>> cheers -ben
>>
>>
>> On Mon, Jun 1, 2015 at 10:36 AM, Ben Coman <btc@openinworld.com> wrote:
>>> I tried, but it seems some packages are missing from the inbox.
>>> cheers -ben
>>>
>>> On Sun, May 31, 2015 at 2:19 PM, stepharo <stepharo@free.fr> wrote:
>>>> Hi
>>>>
>>>> I continued to clean that classes have categories and method protocols
>>>> because it was not finished.
>>>> This entry is just adding protocol in the classes that were missing it,
>>>> adding comments, and fixing some local senders
>>>> It does not remove the category API but puts it in a accessing-backward
>>>> protocol and in a second step I will fix all the senders I can (ie not
>>>> Metacello for example).
>>>> Category is really overloaded and we get lost when trying to understand
>>>> code.
>>>> I want to rename RBRule 'category' into 'kind' for this reason.
>>>>
>>>> Stef
>>>>
>>
>
>