Hi!

On 02/25/2011 11:31 PM, Jeff G wrote:
> Hi Göran,
>
> I understand your point that as things are now there is no way to
> automatically roll back the code that is installed by Squeakmap.

Small correction: There is no way to *100% safely* roll back all *side 
effects* from code that is installed by *any tool* into the image. 
Again, because of class side initialization.

And of course, if you also *run* the code you have installed (like 
playing with it) then in theory it doesn't matter if it doesn't have any 
class side initializers - the code itself can then do whatever it 
pleases like for example remove objects or even classes in your image.

Note - I don't think the danger here is malicious code, but rather stuff 
we hook up and don't have code to undo, like for example registering a 
class for startUp behaviour - or adding menu entries etc. Tools 
typically do lots of these things in order to get "into the image" 
properly. Although this issue may be less these days due to new 
mechanisms using Pragmas perhaps? Not sure.

 >  You
> say God knows what the class side initialization methods do when they
> are run,  but one other person also knows what they do and that is the
> person who wrote them.  I am speaking from a position of deep ignorance
> here but does apt know how to automatically remove packages or is there
> also another side of packaging up software for the repos, which is
> allowing apt to know what to do to remove the software and config files
> as well?

I don't know apt that well, but I do know that some distros add hooks in 
the filesystem layer during installation (Lunar Linux does) and thus can 
track exactly what files were added when a package was installed - and 
can then make sure to remove them all. So Lunar does not rely on any 
manual "list" of files to remove.

Sidenote - of course a Linux package could also do nasty stuff when 
installed, so perhaps there is no real difference after all.

> I remember that Andreas had worked on a protocol a while back to allow
> for unloading various blocks of functionality from the image, such as
> Etoys.  Were the messages called "cleanUp" or something like that?

Just old conventions etc. Not a "protocol" AFAIK.

> I guess what I am saying is that I understand that there is no way to
> automatically remove the software and undo changes that are done to the
> image, but could people encouraged to provide some sort of protocol that
> would be responsible for cleaning up  as well as initialization?
>
> As always, please consider this message as ideas and suggestions and not
> demands or complaints.

Sure!

If we lower our expectations to *usually safe* then one quite nice way 
of getting decent uninstall would actually be to push the Deltastreams 
project forward a bit. That project is based on the Delta class, which 
is like a ChangeSet but much better - and among other things it has full 
undo support. And the Delta part is very close to being 100% done.

So if we had Deltas we could just "record" all changes made when making 
an install (of whatever format!) into a Delta. And then keep that Delta 
around (contrary to ChangeSets Deltas are fully self contained). And 
then for uninstall we would just undo the Delta. The Delta has enough 
state to tell us if there have been other changes made "on top" 
preventing it from getting us back to the original state.

This last problem is exemplified with MC "overrides". In MC a package 
can "override" a method in a class outside of itself. Now, if different 
MC packages override the same method - then stacking them on top of each 
other and then trying to uninstall the previous one will cause this 
problem to arise. Luckily the Delta would detect it.

And finally, as you said - classes should ideally have #release ( 
opposite of initialize) methods I guess if they need to make 
modifications to the image before they get deleted. Not sure if that has 
ever been used for class side initializers - anyone care to elaborate on 
Smalltalk history here?

regards, Göran

PS. MC has unload capability so for MC only it already is there, 
although I am not sure how it deals with the override situation.