On Monday 21 October 2002 04:44 pm, Andreas Raab wrote:

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

Well, sure. But I was also thinking that that would require people to 
first load a CS to get that capability. I suppose if we could get it 
into the update stream(s), that would be OK.

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

In other words, a global. Yes, that seems like the best idea.
Making a separate class to handle this is, of course, a clean way to 
do it.

Then preamble/postscript code could go:

ZipInstaller current loadChangeSet: 'whatever.cs'.
ZipInstaller current extract: 'readme.txt'.
ZipInstaller current extract: 'readme1.txt' to: 'README.TXT'.
ZipInstaller current fileIn: 'misc/whatever.st'.
ZipInstaller current extractDirectory: 'images/'.

etc.

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

It is a bit hackish, but it would let us distribute 
backwards-compatible packages.  I've just learned about  
ChangeSet>>removeSelectorChanges:class: which could be useful with 
covering the installer's tracks.

I suppose, though, we could just say "update your image first".

So the question is: "Is backwards compatibility important?".

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE