Bert Freudenberg wrote:

> What we want (or what I think we should aim for) is that a user installs the squeak-vm
> package from their distro, and that's all to make double-clicking any image work. The
> same should be true if you type "squeak some.image" on the command line, too.
> 
> That requires "squeak" to be a shell script (which it already is, also used in the
> .desktop files) which decides which VM to run based on the image version (this
> part has not been implemented yet). The VM package would contain two VMs. One
> interpreter, plus a Cog (on intel) or Stack VM (other than intel). They might even share
> the plugins.
> 
> The current situation is that e.g. Fedora only has 3.10 VMs which can't even open a
> closure image:
> 
> 	https://admin.fedoraproject.org/pkgdb/applications/Mysqueak
> 
> Debian has more recent 4.x VMs:
> 
> 	http://packages.debian.org/search?searchon=sourcenames&keywords=squeak-vm
> 
> But only the unstable Debian one can open a Cog image, so we think we should not
> release 4.3 as Cog image, yet.

Here is another interesting link to a page that Bert maintains which
shows where Squeak bugs get tracked for all the versions out there
(which is a good first approximation of what versions are out there):

http://wiki.squeakland.org/display/sq/Bug+Tracking

There are two different use cases we are interested in handling. The
first is making things nicer in the future for Linux users. That can be
done with new or changed code on both the image side and the VM
packages. The second use case, which the survey will be for, is making
the 4.3 image usable for users who got their current VMs from their
distribution instead of from squeak.org. In this situation we can't make
any modifications to the VM since these won't get included in all
distributions soon enough to help.

Of course, we have to be reasonable. I am stuck in Fedora 10, for
example (their installation system can deal with RAID in the root
partition, but their upgrade system can't). And during a long time I was
stuck with a 3.7-7 VM because newer ones broke diacritical marks for all
but the Etoys images. It wouldn't make any sense to try to support
someone in that situation. That has been fixed and I now use a
4.0.3-2202 VM. Using that with a proposed 4.3 image gets me

+ exec padsp /usr/local/lib/squeak/4.0.3-2202/squeakvm
Squeak4.3alpha-11636.image
This interpreter (vers. 6502) cannot read image file (vers. 6505).

Here I used the command line. I couldn't test double clicking on the
image file since my system seems to have associated .changes and
.sources files with Squeak but not .image files. It would be nasty if
this failed without even an error message as the above (which is
probably too confusing for many people as it is).

One proposal is to distribute the 4.3 image so it can be loaded by older
VMs. But that just means we will face this problem again for 4.4.

It will take me a while to look at all the Linux systems, but I expect
to see some with no Squeak at all, some with Etoys (so downloading a
Squeak image will use the VM that came with that), some with just the VM
(because of wierd ideas of what Open Source don't allow the image) and
others with VMs and images related by some dependency mechanism. The
last case is the only one we wouldn't have to worry about, at least in
theory.

The situation for Windows and Mac OS X is a little better, but there is
still room for confusion.

-- Jecel