3.3.1 for Unix

Ian Piumarta ian.piumarta at inria.fr
Mon Jun 10 17:21:10 UTC 2002


On Mon, 10 Jun 2002, Lex Spoon wrote:

> David Farber <dfarber at numenor.com> wrote:
> > Hmmm...and should I have expected inisqueak to transform Squeak-3.3alpha-4881.images (and .changes) into squeak.image (and .changes) when they get copied locally? Because without the transformation, I have to specify the image name when I run squeak. Just a nit.
> 
> It would be nice, for packaging Squeak/Unix, if a single VM and inisqueak
> could be used with multiple images.

What I have at the moment (in the devel tree -- not yet in the
tarballs) is this:

  VM tarball/rpm contains "squeak", plugins
  (these all live in /usr/.../squeak/MAJ.MIN-REL/*)
  and doc/man files
  (/usr/.../doc/squeak/*    /usr/.../man/man1/squeak.1)

  Sources tarball/rpm contains SqueakV3.source
  (this lives in /usr/.../lib/squeak/SqueakV3.sources)

  Image tarball/rpm contains .image .changes and inisqueak
  (these live in /usr/.../lib/squeak/*)

inisqueak has moved to the image tar/rpm because it is dependent on the
version of the image you have installed.  The assumption is that you
install the latest image from tar/rpm and you want new users who run
inisqueak to pick up the latest image by default.

If there's a real need for a command-line argument to inisqueak (or for it
to scan the /usr/.../lib/squeak dir and propose a list of image versions)
this is above 3 minutes work to add.

>  Here's how the packaging is set up
> with the Debian Squeak packages right now, for example:

Looks pretty close (modulo inisqueak coming with the image tar/rpm).

> The SF inisqueak works with any installed image.  It does this by looking
> in a standard location (eg /usr/share/squeak) for files named squeak.image
> and squeak.changes.  Typically, these are symbolic links to the real image
> and changes files.

What's the difference between having links in there and having a new
inisqueak (with version number screwed in) installed along with a new
image tar/rpm?  I can't really see overwhelming advantages to either,
except maybe that the .spec files are lots simpler with explicit image
name.  (Between %prep and %files there is precisely one line of content in
all of the current .spec files, and no need whatsoever for %pre or %post
to fiddle with symbolic links.)

> Incidentally, this versioning scheme shows that you don't need
> versioned subdirectories of things like /usr/lib/squeak.  It's
> just a small simplification, but everything helps!

I caught that one already. ;)   Since two or three days ago the image and
changes live in the version independent dir along with the .sources.

Regards,

Ian





More information about the Squeak-dev mailing list