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
|