scratch team mailing list archive

[Amos Blanton <amos@xxxxxxxxxxxxxxx>]

Hi Kevin,

Ah - as Bert said, it would be better to depend on a shared squeak-vm rpm.
It would be good to test things out first, but it should work. We bundled
our own with the ubuntu version because the one available for us to depend
on in the Ubuntu repository had a very old bug. But we'd prefer to do things
right, and probably will when the Ubuntu vm gets updated.

-Amos

On Mon, Mar 22, 2010 at 7:23 PM, Kevin Somervill <ksomervi@xxxxxxxxxxxxxx>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?  I was just trying to package the tarfile
> scratch has posted.  /usr/lib is a weird place to put the vm since it's not
> a library.  Since it's executable, but it doesn't look like folks are
> expected to use it directly, it's a candidate for libexec.  IMO, it would be
> better to use a squeak distributed vm that is shared with other
> applications.  It's another rpm to go track down, but that's not a big deal.
>  Other packages in a similar situration will often offer both (i.e. the
> whole enchilada or separate packages).  I'll leave it up to the scratch team
> as to how they want it packaged.
>
> <snip>
>
>
>  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
>



-- 
_____
Amos