Issue 4394 in pharo: GoferApiTest >> testRepositoryErrors fails in Full but not in Core

Status: Accepted
Owner: [hidden email]
Labels: Type-Bug Milestone-1.3-DevImage

New issue 4394 by [hidden email]: GoferApiTest >>  
testRepositoryErrors fails in Full but not in Core
http://code.google.com/p/pharo/issues/detail?id=4394

GoferApiTest >> testRepositoryErrors fails in Full but not in Core


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Cc: [hidden email]

Comment #1 on issue 4394 by [hidden email]: GoferApiTest >>  
testRepositoryErrors fails in Full but not in Core
http://code.google.com/p/pharo/issues/detail?id=4394

So the very strange thing is that in Core, we have

Gofer-Tests-MarcusDenker.129

but in Full, it is magically replaced by an on old version:

Gofer-Tests-StephaneDucasse.129

The reason is ConfigurationOfGofer loads the old version with the faulty  
test.

Now a brave soul needs to to

  -> update Configuration of Gofer
  -> Find our who load it and change that package to load the correct  
version of the updated Gofer package.




_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: FixProposed

Comment #2 on issue 4394 by [hidden email]: GoferApiTest >>  
testRepositoryErrors fails in Full but not in Core
http://code.google.com/p/pharo/issues/detail?id=4394

(No comment was entered for this change.)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #3 on issue 4394 by marianopeck: GoferApiTest >>  
testRepositoryErrors fails in Full but not in Core
http://code.google.com/p/pharo/issues/detail?id=4394

I think this is because of the version that Metacello bootstrap loads from  
Gofer.
Dale, any idea how we can fix this?


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #4 on issue 4394 by marianopeck: GoferApiTest >>  
testRepositoryErrors fails in Full but not in Core
http://code.google.com/p/pharo/issues/detail?id=4394

We should be using Gofer-Tests-MarcusDenker.130  from Pharo repository.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #5 on issue 4394 by [hidden email]: GoferApiTest >>  
testRepositoryErrors fails in Full but not in Core
http://code.google.com/p/pharo/issues/detail?id=4394

Metacello should not be loading an older version of a package ... that  
would be a bug a bug in Metacello ... I thought that that bug was fixed in  
Metacello 1.0-beta.29 ... which build is this happaing in? 1.2, 1.3 or 1.4?


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #6 on issue 4394 by [hidden email]: GoferApiTest >>  
testRepositoryErrors fails in Full but not in Core
http://code.google.com/p/pharo/issues/detail?id=4394

ah ... now I see .. 1.3 ... I'll take a look


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #7 on issue 4394 by [hidden email]: GoferApiTest >>  
testRepositoryErrors fails in Full but not in Core
http://code.google.com/p/pharo/issues/detail?id=4394

oh wait ... I see the problem now ... When gofer is deciding which package  
is newer:

   Gofer-Tests-MarcusDenker.129
   Gofer-Tests-StephaneDucasse.129

if first uses the version number, but for these two packages have the same  
version number (129), so gofer then goes to the author name and  
StephaneDucasse sorts after MarcusDenker so Gofer thinks that  
Gofer-Tests-StephaneDucasse.129 is the later package and Metacello (which  
has StephaneDucasse.129 specified in the config) goes ahead and loads  
the "newer version"...

A checkin using using a version number greater than 129 or an author  
starting with a letter greater than 'S' will "fix" the problem ...


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #8 on issue 4394 by [hidden email]: GoferApiTest >>  
testRepositoryErrors fails in Full but not in Core
http://code.google.com/p/pharo/issues/detail?id=4394

Mariano,

When you say "We should be using Gofer-Tests-MarcusDenker.130  from Pharo  
repository." are you referring to PHaro-Core 1.3 or Pharo-1.3 ... if  
Pharo-Core loads Gofer-Tests-MarcusDenker.130, then Metacello will  
stop "loading Gofer-Tests-StephaneDucasse.129" ... if  
Gofer-Tests-MarcusDenker.130 needs to be used in on Pharo-1.3, then the  
configuration of Gofer needs to be adjusted ...


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #9 on issue 4394 by marianopeck: GoferApiTest >>  
testRepositoryErrors fails in Full but not in Core
http://code.google.com/p/pharo/issues/detail?id=4394

Hi Dale. The latest commits are from Marcus, so I am NOT completly sure  
about my answer. My gut feeling is that when building Pharo, the Gofer  
version of PharoCore should not be changed. I mean, if in PharoCore there  
is teh version Gofer-Tests-MarcusDenker.130, then such version should stay  
there in Pharo, because such version has fixes for Pharo....so if we then  
load a different version, we have the problem like the one on this issue in  
particular.

So..the real question is whether Metacello should install Gofer if Gofer is  
already present in the image. I don't know :(   If it does that, then yes,  
we should update ConfigurationOfGofer so that to use that version. But at  
the same time, you did commits in the repo of Gofer, didn't you?  So we  
need to merge?


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #10 on issue 4394 by [hidden email]: GoferApiTest >>  
testRepositoryErrors fails in Full but not in Core
http://code.google.com/p/pharo/issues/detail?id=4394

Mariano,

if and when Gofer-Tests-MarcusDenker.130 is actually loaded into the core,  
Metacello will not load an older version on top of the version that is  
installed ...

Monticello/Gofer/Metacello is flawed in that it is necessary from a  
performance perspective to use the name of the mcz file to determine  
version information, so this whole issue is down to a) Metacello requiring  
Gofer-Tests-StephaneDucasse.129 while the core has loaded a "later version"  
of the mcz file (Gofer-Tests-MarcusDenker.129) that Gofer thinks is an  
older version... I don't consider this a bug in Metacello, because there is  
no way to fix it, without changing the behavior of Gofer ... perhaps it is  
a Gofer bug:), but as far as I can tell it's a 50/50 proposition at this  
point, so there is no adequate resolution.

As for should Metacello install Gofer? If Metacello (or any other project)  
truly does require a later version of an mcz file than is already installed  
in whatever image it is being loaded into, then of course, it should  
install the newer version ... whether or not an older version was already  
installed or not ...

I don't see the need to do any merges ... you'll have to be more specific  
with the details of what you think needs to be merged,

For Pharo 1.3, the deadlock between Gofer-Tests-MarcusDenker.129 and  
Tests-StephaneDucasse.129 needs to be resolved by someone on the pharo team  
(presumably marcus), by committing a new version of  
Gofer-Tests-MarcusDenker.129 or using Gofer-Tests-MarcusDenker.130 and then  
loading the appropriate package in the core ...

Either way, once a human being decides which code they want in Pharo 1.3,  
that human must ensure that the version number of the package has been  
incremented beyond 129 so that Gofer/Metacello will make the right decision  
on which version is "newer". Once that is done, I don't believe that  
neither the Gofer configuration nor the Metacello configuration needs to be  
chnaged...


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: Closed

Comment #11 on issue 4394 by [hidden email]: GoferApiTest >>  
testRepositoryErrors fails in Full but not in Core
http://code.google.com/p/pharo/issues/detail?id=4394

I saved a new version and now it's working! All Green


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker