Zip-based Squeak distributions -- ideas needed

danielv at netvision.net.il danielv at netvision.net.il
Tue Oct 22 04:41:18 UTC 2002


Make it one of SqueakMap's installers, and thus 
1. It will probably get in the image pretty soon.
2. Such packages will then become a SM supported format, and thus even
more useful.

Daniel Vainsencher 

Ned Konz <ned at bike-nomad.com> wrote:
> 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



More information about the Squeak-dev mailing list