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/MetacelloUserGuide.md#locking


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 ...


Reply via email to