Zip-based Squeak distributions -- ideas needed
Andreas.Raab at gmx.de
Mon Oct 21 23:44:49 UTC 2002
> I was just playing around with making a zip-based Squeak distribution
> format that could be used for multi-CS packages.
> What I need help with is this:
> For backwards compatibility, the entire logic has to live in the
> self-extracting stub at the front of the zip.
Duh ... I'm not sure if that's a good idea. Have you considered using
something like a ".cs.zip" extension (similar to .cs.gz) to indicate
that this is a "multi changes" file?! Then all you'd need is to modify
the file list to recognize it.
> The problem is that the preamble and postscript code won't know what
> zip file is being installed, so they can't do anything intelligent.
> I'd like either the zip stream, or the zip itself (better) to be
> available to this code, but that's hard to do, because there is no
> context for the compilation of the various chunks.
> I'd thought about using a global (the easy way out), but that wasn't
> too appealing.
> Another problem is that the self-extracting stub methods are logged
> and added to the current CS. I'd like the (re-re-re-) definition of
> the methods in the stub not to be logged.
What I'd be doing is to make up a "ZipInstaller" class which handles all
of this in any way it wants. For accessing the current context use
"ZipInstaller current" (which could return nil if it's a "regular
fileIn"). For the logging - don't use the self-extracting stug. Just
make it part of the proper installation logic.
While I can see why you would like it to be "just like a fileIn" I'm
uncertain about how good of an idea that really is. There's too much
hackery involved for my taste.
More information about the Squeak-dev