Hilaire, I mentioned last night that I thought that there was a better solution to your problem and I think that if you load the latest Metacello and then lock Seaside3: Metacello image configuration: 'Seaside3'; version: '3.1.5'; "most recent 3.1.x version" lock. Then load Voyage, you shouldn't have the problem with Seaside being updated to 3.2. Seaside does not support upgrade across minor version numbers like 3.1 to 3.2 ... if the upgrade to 3.2 was allowed, you wouldn't have this particular problem. The Metacello lock command was invented so that a developer could take ownership of the version of the projects used in their image. It is not always desirable to upgrade to a later version of a project without extensive testing (whether or not the actual load to the new version is successful), so the lock command allows you to control which versions of projects are loaded by Metacello by overriding the choices made by other developers ... You can even lock versions of projects that are not yet loaded. I am still curious as to my Seaside and Magritte are linked together --- I suspect that somehow the Magritte-Seaside package got loaded and once that happened you were off to the races. Dale [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUser... On 2/18/17 7:32 AM, Hilaire wrote:
Dale,
May be you don't want to waste anymore time on that. Thanks for your effort. I got a way to get Voyage installed in my development image.
Not sure what wrong, because something is wrong[1], but I got the things installed, first update to Seaside, which break when upgrading the Seaside installed from the configuration browser, fix the seaside broken installation, then install Voyage which went fine. Did not test Voyage is working though.
Hilaire
[1]The Pharo4 configuration browser's Magritte3 is installing Seaside update, this should NOT happen. Now image comes with a Configuration Browser, if I understand correctly its intend, an user is expected those configurations to work happily together, but it looks like not, some configurations will request update breaking package previously installed from this configuration browser. May be it is more a policy problem on the quality of the configuration than a tool problem, a lot can be learn from Debian packaging. For example Debian stable is released only when quality is ok, don't know the details but they don't like to rush for release and people complain new stable release take too much time to emerge, the price for quality? For me Pharo fells too fuzzy, and it makes me very sceptical for reliability; may be not nice to write and to read but it is how I fell. I may be biased and I don't mean bad to anyone writing this, I know how quality is hard to achieve and Pharo teams did great endeavour in many aspects.
Le 17/02/2017 à 22:15, Dale Henrichs a écrit :
Again, thanks for detailed info ...
The fact that you loaded Seaside3.1.x is good enough for my purposes .. the fact that Seaside3.2 is getting installed implies that there is a hard dependency on Seaside in one of the projects (Magritte3 perhaps?) ... odd that ConfigurationOfSeaside3 wasn't downloaded this time around --- Can you get the package version of ConfigurationOfSeaside3 that's in the image after the `Metacello new` loads?... I'll have to dive into the configurations now ...