On Monday 07 February 2005 4:39 pm, Doug Way wrote:
> > > .sar files are good for installing things like fonts or arbitrary data
> > >   into an image, but there's not a pressing need to have those be
> > > unloadable either.
> >
> > Right, on the other hand we might need them for packaging resources.
> > So perhaps we could "tag" them somehow? As in "this .sar file is
> > uninstallable, because it only has .mcz files and a proper postscript".
> > Eh... would it also need a uninstall-postscript then perhaps? Hmm. :)
> >
> > Anyway, let's dump that issue on Ned and Avi. :) I will mail them.
>
> OK, I'm sure something could be worked out there.

Right now the following two zip members are optional in a SAR (if neither are 
present, each member will be loaded in the order in which it appears in the 
zip archive/directory using a default load method based on member name 
extension):

install/preamble -- run at the beginning of installation
install/postscript -- run at the end of installation

I suppose that we could add corresponding uninstall/ entries:

uninstall/preamble -- run at the beginning of installation
uninstall/postscript -- run at the end of installation

If either of these is present, we could take this as an assertion that the 
effect of the SAR is reversible by running them. But how would you test for 
that without taking a snapshot of the entire image before you load each SAR?

And if the SAR is a 'DWIM' one (i.e. no install/preamble, install/postscript, 
uninstall/preamble or uninstall/postscript) and consists only of things we 
*know* to be unloadable (like MCZ files where we can determine the package 
names from the member names, and then look for the PackageInfo objects that 
correspond to these, and ask *those* if they're cleanly unloadable) it too 
would be unloadable (if there were no interactions between any of its 
packages or anything that was loaded later).

-- 
Ned Konz
http://bike-nomad.com/squeak/