Hi Ned,

> I was just playing around with making a zip-based Squeak distribution 
> format that could be used for multi-CS packages.

Nice idea.

> What I need help with is this:
[snip]
> 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.

Cheers,
  - Andreas