Hi Ned!

Ned Konz <ned at squeakland.org> wrote:
> 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?

Well, we would just have to "trust" the package maintainer. :)

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

Yes, but such .sar files are less interesting, because I assume people
tend to use .sar files when there are extra resources they need to
bundle (like say .png files) and then they need to use
preamble/postscript to actually get that stuff installed - right?

Anyway, I think this sounds fine - though for SM to work properly it
needs to be able to determine "uninstallability" without having the
actual file. Well, it would typically be available in the cache dir -
but that seems ugly. Better to have some SM category called
"Uninstallable" and then make sure it gets set properly (SM could help
with that). That way the SqueakMap Package Loader can offer the
uninstall option just by looking at category. Eh... and right, having
those uninstall scripts in the .sar file seems a bit awkward when you
think more closely - what if I don't have the file available? :)

regards, Göran