Uninstalling stuff (was Re: [squeak-dev] SqueakMap for documentation?)
goran at krampe.se
Fri Feb 25 23:04:18 UTC 2011
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.
> 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.
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?
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.
More information about the Squeak-dev