[Vm-dev] Fwd: Nix package for Pharo flavor of opensmalltalk-vm
btc at openinworld.com
Thu Apr 20 14:19:20 UTC 2017
Moved thread back to pharo-dev for image-side nix packaging discussion.
On Thu, Apr 20, 2017 at 3:59 PM, Luke Gorrie <luke at snabb.co> wrote:
> On 20 April 2017 at 06:03, Ben Coman <btc at openinworld.com> wrote:
>> On Thu, Apr 20, 2017 at 12:21 AM, Luke Gorrie <luke at snabb.co> wrote:
>>> Then you can start one of those images with these shell commands:
>> Since Pharo 6 is not yet released, what are the implications of naming those
>> pharo-6.dev & pharo64-6.dev [minor edit]
> On reflection I will split up my packaging work into "vm" and "image" components. I will send the vm upstream ASAP. I will leave the images on a development branch, perhaps indefinitely, because I am not sure that I am on the right track there at all.
That sounds like a good approach.
> So, here are more thoughts on image packaging, but with the disclaimer that I will probably not actively pursue this topic further at the moment:
> I assert that Pharo 5 and Pharo 6 are both released,
The "release" event will create the PharoV60.sources file,
null out the .changes file (it gets incorporated into PharoV60.sources)
and Pharo 7 development on will commence.
None of those things has happened yet.
Last I read, this was due in May, similar timeframe to Pharo 5 release
> and are both fast-moving targets.
The attached chart shows the dev-image build rate.
There is a clear change in Pharo 5 build rate after it was released on 12-May.
What happens is that during Pharo-6-development, a critical bug was
fixed and deemed worthy to backport to Pharo 5. That doesn't put
released-Pharo-5 and in-development-Pharo-6 on equal footing.
Perhaps for packaging for distributions we need a modified process
for post-release-updates, such that the released image remains
constant and upon startup notifies that there are updates available to
> On http://pharo.org/download there is a prominent link to Pharo 6 as the "development version" ready for download. Anecdotally the Pharo community that I interact with (mailing list, twitter, slack chat, etc) seem more focused on Pharo 6 than on Pharo 5.
The greater focus on Pharo 6 is because it is "in development"
and you are talking to pharo-developers.
> Occasionally people express surprise when I tell them I am "still" using Pharo 5.
On the one hand, that might be considered overzealous recommending
alpha/beta software for your primary platform. On the other hand,
in practice many find the bleeding edge consistently very stable.
(opinion depends on the exact critical nature the application)
The thing is, if you hit a bug in the in-development version, it can
get fixed quite quickly. More Pharo-developers work on the HEAD,
so its self interest to get things working smoothly. Policy is that *all*
fixes must *first* be done in the in-development-version. Only critical
fixes get backported to the released-version. So if you hit a bug in
a released-version, you might not see the fix before the next release.
So there is a lot of benefit following the tip of development.
> On http://files.pharo.org/image/50/ there is a new release of Pharo 5 every few weeks. This means that each time I have downloaded "Pharo 5" in the past I have probably gotten a different image and a different VM. So from my end-user perspective I have no idea what software I am installing regardless of whether I choose Pharo 5 or Pharo 6.
I consider this moving target for a released version (i.e. Pharo 5) a
problem. Personally I'd like to see post-release versionning like
but other seem to disagree, or maybe its just resourcing.
Pharo 6 is "in-development" so different rules apply.
Personally I never use the "latest" download.
I manually choose the latest build using PharoLauncher (couldn't live
> So as a nix user it would make sense for me to be able to download both Pharo 5 and Pharo 6 and for the nix package definitions to determine exactly which software I am running (as opposed to getting an invisible update from Pharo upstream every few days/weeks potentially leading to "but it worked fine on my other machine..." sorts of problems that are exactly what can nix protect me from.)
I agree with you wrt to a released-Pharo-5, but not in-development-Pharo-6.
>> Packing the other images is maybe also wrong. How would you deal with user state being stored in the image when a new build download in available?
> The ad-hoc idea that I ran with is this:
> Running a script like pharo-5.0 (or moose-6.1, etc) will make a temporary copy of the image in the current directory. The changes file will be read-write (requirement) but the image file will be read-only. The model is "you saved it, you own it" i.e. if you want the image to survive after exit you need to "Save image as..." and once you do that then you are responsible for it.
I hardly ever use "Save image as...", just "Save" and I think that might
confuse existing users if they *need* to do it. Probably workable would be
having the "Save image as..." dialog appear the first that "Save" is chosen.
> Code: script to run an image and script to start the right vm.
> I am not sure why "Save image as..." is misbehaving for me. I have tested every combination of read/write permissions on the working directory, the image, the changes file, etc, but it was always the same. I am sure that I can work this out via the Smalltalk debugger -- but at the moment it seems to make more sense to focus on the VM than on the images. (I want to wrap this up.)
> The downside to skipping the images is that I don't maintain feature parity with Damien's original nix packaging. He packaged the launcher image and then that was the gateway to everything else. This solution doesn't feel very solid to me, since now in 2017 I don't think the launcher is accounting for all the different VM requirements properly, but I am not willing to pick up maintenance of that image so that is life.
Skipping Images is different to skipping Launcher. The Launcher
provides a *static* vm+image that is used to manage Images to solve
"movign target" problem you are hitting. Launcher could perhaps do
with some further extension to distinguish 64-bit Images, since that
requirement has only arisen in the past year, and also perhaps be able
to manage multiple VMs, instead of just the pre-Spur & Spur VMs
configured in its settings. But otherwise Launcher works fairly well.
If feasible, I'd suggest that you separately package the VMs, and then
have a package for PharoLauncher that depends on that package.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 44235 bytes
Desc: not available
More information about the Vm-dev