scratch team mailing list archive

[Bert Freudenberg <bert@xxxxxxxxxxxxxxx>]

On 23.03.2010, at 00:23, Kevin Somervill wrote:
> 
> MC Bert Freudenberg cold spun it on 03/22/2010 05:35 PM:
> <snip>
> 
>>> 
>>>    How attached are you to having the files in /usr/lib/scratch?
>>>    These are the Plugins, Scratch.image, and scratch.ini files and I
>>>    think they should be in /usr/libexec/scratch, as well as the
>>>    scratch_squeak_vm. 
>>> 
>>> I'm pretty sure it's fine to move these, but the final answer depends on the way paths are coded inside the Scratch.image, about which I'm not certain. I suspect there are absolute path references to the media / help / language files, but probably not to the Plugins, image, and vm. So if everything works when you set it up that way, that's proof enough. :)
>> Everything is coded relative to the image location. The VM path does not mater at all.
>> Since the image and media are platform-indepent, /usr/share would be the right place. Plugins and vm are platform-dependent, so /usr/libexec would be fine. The squeak vm and plugins are traditionally in /usr/lib but it doesn't really matter. And it sounds like you want to copy the vm instead of sharing with the other squeak-based apps?
> 
> What other squeak based apps? 

The major other app is Etoys, packaged by Gavin Romig-Koch. He also made the Fedora squeak-vm package. His packaging repo is at
http://code.google.com/p/squeak-fedora/
That squeak-vm package is missing some of the vm plugins Scratch needs. The Scratch folks developed those plugins but they are not upstream yet, though they properly belong into the same squeak-vm package. But I guess Gavin would be open to just include them, even though they come from a different source.

Squeak itself is a programming language/environment. The VM is shared by projects like Scratch, Etoys, OpenCroquet, OpenCobalt, Seaside, Pharo, Cuis, etc. All of these provide their own "images". Most of them have not been packaged yet. In fact, since (except for Scratch and Etoys) they are aimed at developers rather than users, it's unclear if packaging them even makes sense - it would be like packaging source tarballs for other projects. Squeak developers typically just download an image to their home directory and start hacking, just as in other projects they would download a source tarball.

Anyway, one could say that the official packaging efforts are still in flux, because they only started recently, even though Squeak itself is around since 1996. Squeak is amazing but quite different and we still need to figure out best packaging practices.

A good place to discuss this would be the Squeak VM developers list:
http://lists.squeakfoundation.org/mailman/listinfo/vm-dev
There is also a list José created specifically for packaging, but it's underused:
https://alioth.debian.org/projects/pkg-squeak/

>>> re: pulse plugin -- The ALSA plugin should work just fine on systems without pulse, and performance should be the same, so just use it. We had to make (or rather, we begged our friend and contributor Derek O'Connell to make for us) the pulse plugin because the existence of pulse broke the ALSA plugin on Ubuntu systems. So if you don't have pulse, use ALSA.
>> In case you still need code to detect pulse, there is some near the end of the etoys wrapper script:
>> http://etoys.laptop.org/src/etoys.in
> Thanks. It looks like the scratch wrapper could use this to select either the pulse or alsa plugin.
> 
> ./ks

You're welcome. 

And thanks for taking this on! I'm just an upstream Squeak developer, not packaging for any distro myself. But I ported Etoys to the OLPC/Sugar platform and so got more involved with package maintainers than possibly any other Squeak developer out there :)

- Bert -