OK.  The reason I ask is I'm a bit concerned that the Debian maintainers
might push back on, or even reject, a combined VM package as it would
likely be harder to follow from a package organization standpoint and
therefore more difficult for them to maintain.  If the main objective is
that we have a unified launch script, we could do that pretty easily with
multiple packages: one for the classic VM, one for the stack/cog/spur VM
and one for the launcher script (which could be a dependency of both VMs
and therefore automatically installed.)  The launcher script could then
detect which VM(s) are installed and either launch the appropriate one or,
if it is not available, suggest the user install it.  Would that be an
acceptable approach or would you prefer to pursue a single unified package?

Whichever way we proceed, contact should probably be made with the Debian
maintainers to at least let them know a significant change is coming and
see if they have any feedback that needs to be taken into consideration.
Does the Board already have someone who would handle that or would you like
me to?

On a related note, I've been busy dusting off my packaging knowledge: over
the weekend I managed to get a package-based VM to build manually using a
skeleton package.  Still a fair amount to do before I'd call it 'usable',
but it did confirm that the basic build part of the equation shouldn't be a
big deal which I was hoping would be the case.

P.S. Oh wow!  Just looked at the http://files.squeak.org/debian/ link...
people should definitely be steered away from using that unless they have a
specific reason to still use that.  The package already in the Debian repos
is definitely more current and usable (for older images) on recent Debian
releases... there are only a handful of patches they've applied.  Should I
forward them to Dave for review?

On Sun, Jun 20, 2021 at 12:45 PM Vanessa Freudenberg <vanessa at codefrau.net>
wrote:

> Don’t think so.
>
> Vanessa
>
> On Sat, Jun 19, 2021 at 16:04 Phil B <pbpublist at gmail.com> wrote:
>
>> Vanessa,
>>
>> Thanks for filling in some of the gaps for me.  It does change the scope
>> a bit from what I had envisioned.  I was thinking that this was an effort
>> to package up the modern VM as a separate package from the classic VM
>> rather than integrating it with the existing classic VM package.  Has
>> anyone run the plan by the Debian maintainers yet?
>>
>> Thanks,
>> Phil
>>
>> On Sat, Jun 19, 2021 at 1:27 PM Vanessa Freudenberg <vanessa at codefrau.net>
>> wrote:
>>
>>> Yes it’s the source for the existing “squeak-vm” Debian package we are
>>> talking about. The Debian “etoys” package depends on it.
>>>
>>> We are “upstream”,  the maintainers at Debian take our latest tar ball
>>> from http://squeakvm.org/unix/release/ and build a new package.
>>>
>>> The latest Debian version is therefore 4.10.2.2614, corresponding to our
>>> latest tarball in that directory, so from their point of view it’s up to
>>> date. From our point of view it’s slightly outdated, since that tarball was
>>> created in 2012. It contains an interpreter VM for pre-Spur 32 bit images
>>> that compiles and runs fine on both 32 and 64 bit architectures.
>>>
>>> That VM can not run recent Squeak releases anymore, because it cannot
>>> read Spur Images. It can also not run 64 bit images. And it also is much
>>> slower than Cog VMs.
>>>
>>> The plan is therefore to add a VM that can run Cog / Spur images to that
>>> bundle. The script that starts the image needs to be extended to check the
>>> image  format number and launch it with the right VM.
>>>
>>> That means the tarball needs to contain two source trees: the existing
>>> one for 6502 images (like Etoys), and another one 6504 images and later
>>> (any Squeak image since 4.1). We only have JITs for Intel and ARM, so on
>>> those arch we can compile Cog, on all other platforms we would compile
>>> StackVMs (or maybe compile Stack for every arch, and Cog where possible).
>>>
>>> In addition we might want to check if we should upstream any of the
>>> patches the Debian maintainers did over the years. And maybe add a README
>>> to
>>> http://files.squeak.org/debian/ that those packages are superseded by
>>> the official Debian package.
>>>
>>> Thank you! I think that will be a fun and useful project. Overdue too 😅
>>>
>>>
>>> - Vanessa -
>>>
>>>
>>>
>>> On Thu, Jun 17, 2021 at 19:20 Phil B <pbpublist at gmail.com> wrote:
>>>
>>>> Assuming you are looking for someone to create/update the Debian source
>>>> package (i.e. to update the package in the Debian repos) and not just a
>>>> standalone tarball that builds on Debian, I'd be willing to do it.  While I
>>>> don't live and breathe creating Debian source packages, I have had to do it
>>>> from time to time over the years.
>>>>
>>>> On Thu, Jun 17, 2021 at 3:28 PM tim Rowledge <tim at rowledge.org> wrote:
>>>>
>>>>> Oh, yeah. $500 bounty.
>>>>>
>>>>> > On 2021-06-16, at 10:34 AM, tim Rowledge <tim at rowledge.org> wrote:
>>>>> >
>>>>> > Is anyone out there interested in, and able to spend the time, to
>>>>> try to sort out an update of the Debian tarball stuff?
>>>>> >
>>>>> > A long time ago we went through some considerable effort to get
>>>>> Squeak into the system and it seems to have languished ever since. It would
>>>>> make us look somewhat more contemporary if we could get an updated package
>>>>> built and inserted.
>>>>> >
>>>>> > Please, if you can help, let us know.
>>>>> >
>>>>> > tim
>>>>> > --
>>>>> > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>>>> > Strange OpCodes: RWD: Rewind Disk
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>> tim
>>>>> --
>>>>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>>>> Useful random insult:- Cackles a lot, but I ain't seen no eggs yet.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210620/00a270ff/attachment.html>