Re: [Vm-dev] Fwd: Nix package for Pharo flavor of opensmalltalk-vm

>
> On Thu, Apr 20, 2017 at 3:59 PM, Luke Gorrie <[hidden email]> wrote:
>>
>> On 20 April 2017 at 06:03, Ben Coman <[hidden email]> wrote:
>>
>>> On Thu, Apr 20, 2017 at 12:21 AM, Luke Gorrie <[hidden email]> wrote:
>>>>
>>>> Then you can start one of those images with these shell commands:
>>>>
>>>> pharo-6.0
>>>> pharo64-6.0
>>>> pharo-5.0
>>>> moose-6.1
>>>> pharo-launcher-2017.02.28
>>>
>>> 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
> last year.
>
>> 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
> install.
>
>>
>> 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
> 5.0.x,
> 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
> without it)
>
>
>>
>> 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[1] and script to start the right vm[2].
>>
> [1] https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/development/pharo/images/build-image.nix#L27-L33
> [2] https://github.com/lukego/nixpkgs/blob/pharo6/pkgs/development/pharo/wrapper/pharo-vm.sh
>
>
>> 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.
>
> cheers -ben
>
>>
>> Cheers,
>> -Luke
>>
>>
>>

>
> On 20 April 2017 at 09:59, Luke Gorrie <[hidden email]> wrote:
>>
>> 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.
>
>
> On further reflection it is possible that I am on the wrong track with the VM packaging too.
>
> Pharo upstream are distributing releases as binary vm+image pairs with some third party libraries included. The most faithful way to package this for nix would be to take these binaries and make them work (using patchelf to fix up the shared library paths.) This is how people package other binary software for nix e.g. Skype.
>
> The advantage of this approach would be to faithfully reproduce the software as it is released from the Pharo project. This way nix users would expect the software to work equally well as on Ubuntu or Fedora, say. This would also ease support because Pharo upstream would never be bothered by users having problems due to my packaging e.g. using the latest VM with an older image release if that is not supposed to be supported.

> Hi Ben,
>
> Thanks for explaining the process for maintaining the stable vs development
> versions and illustrating it with data.
>
> I need to understand the Pharo Launcher better. Could indeed be the best
> strategy is to focus on supporting that well. That's basically the approach
> that Damien has taken with the current nix packages.
>
> Hopefully we can work out the optimal way to package Pharo once 6.0 has
> shipped and people have more bandwidth. Just now I have a hard time
> understanding what VM+image combinations are considered to be "supported"