First, my apologies for providing no more than my weak and 
inexperienced observations as a first message to this list. With more 
Squeak time under my belt I hope to be useful in the future by way of 
contribution instead of observation. In the meantime, I wonder if the 
potential ill effects related to these observations is 
underestimated/underappreciated.

I have observed that it is somewhat unreliable to do "in place" 
updates of packages for other than "base" image packages. In other 
words, if a package is already installed and there is an update 
available for that package installing the update regularly results in 
an unreliable image. The anomalies manifest themselves mostly as 
runtime walkbacks or errors during installation of a package update. 
This is not in ALL cases but these days it feels like a 50-50 
proposition. I have found that the only reliable means of arriving at 
a stable image which includes package updates is to go back to 
scratch and install packages in my usual and customary sequence 
(arrived at admittedly with my own brand of "cargo culturalism"). 
There are probably more likely culprit packages for these problems 
than others but I don't relish the idea of having to keep a 
"knowledge base" of sorts for avoiding these problems. I find this 
phenomenon time wasting.

The cause for this problem seems mostly due to lack of a clear 
process, lack of consistent application of said process, or lack of 
discipline regarding package management [which could all readily be 
attributed solely to me...mea culpa :)]. However, at this stage I'm 
mostly a "package user" and not much of a producer so it's not clear 
to me what I could do to mitigate the situation other that what I'm 
already doing (rebuild from "scratch") or simply stop using any 
"add-ons" (bummer, there's some neat stuff to [re]use). As I 
understand it there are some packages which actually modify classes 
(add/remove/change methods) as part of their installation. In some 
respects this would seem to be more error prone than the Java 
situation. When "dropping in" a JAR, for the most part, you aren't 
modifying any "sitting binaries" as seems to sometimes be the case 
with Squeak. Sure, you have all the JAR/Package path resolution and 
compilation issues that come with Java (which I absolutely hate along 
with many other dislikes of Java) but at least I can be relatively 
sure about the insides of those deployment elements not having been 
changed (except by the odd cosmic ray or such). Ideally, I'd like to 
see the "repository/image" approach of Smalltalk with some 
"packaging" concepts borrowed from Java (and at one time was working 
on a custom class loader for Java which used a repository as its 
source).

I haven't dealt with this set of "packaging" issues much using 
VisualWorks so I can't say much about how better or worse it may be 
than Squeak. I do know that it feels as though I spend much more 
[particularly tedious and repetitive] time "policing" my development 
environment in response to package changes in Squeak than I seem to 
have to in Java. This seems to be an issue with Smalltalk that goes 
back to my first days with Digitalk Smalltalk/V. Don't get me wrong, 
I MUCH prefer Smalltalk to Java, but this is one of those nits that 
inhibits efforts to proselytize. I seek to do only more with 
Smalltalk but feel I need to find a way to overcome this set issues 
before I could take my work to a wider (decidedly non-Smalltalk) 
audience.

Thanks ahead of time for any feedback and I hope this didn't come 
across as a rant.

-- 
----------------------------------------------------------------------
Anthony Anton        3800 243rd Place SE          Phone:  425-313-1024
                      Issaquah, WA 98029           Cell:   425-444-3084
Concept Systems      agantoniii at earthlink.net     FAX:    425-313-1042