OBS file generation

[guillep]

Put the generation of OBS files into the VM repo to allow for easier updates of dependencies and so on.
OBS files are templates and their meta-data is replaced at build time by CMake using the same version info as for the rest of the packages.

Usage

cmake --build xx --target package

This creates a package obs with the corresponding files to deploy (in addition to the source files).
Still, when pushing the files to obs, the source archive should be named like [PACKAGE_NAME]-[VERSION].tar.gz

Still todo:

• decide the version naming
• automate the final package (containing both obs files and sources with correct naming)

[noha]

For the version naming I think there is two important points: The vm should version its own progress independent of the image. So 10.x.x is fine and with a new leap 11.x.x.
Second is that no matter what version naming there is we need a mapping table that says which vm version can run which image version. This is inevitable and even more reason the vm version should not follow the image

[noha]

btw. good move with this PR 🕺🏼

[guillep]

As for the table, we have this: https://github.com/pharo-project/pharo-vm/wiki/Versions,-Builds-and-Branches which I did a couple of weeks ago.

We can make the next major version pharo-11, that's ok to me

GitHub

Versions, Builds and Branches

This is the VM used by Pharo. Contribute to pharo-project/pharo-vm development by creating an account on GitHub.

[guillep]

We discussed this in the team, we decided to have a package structure as follows:

• Multiple pharo-vm-[major]-[minor] packages, one per major/minor. Package managers allows us to install a specific version of a package, but not having two versions of the same package installed at the same time. Thus, we need a different package per important version. This package will be versionned using the VM version numbers.
  • See https://askubuntu.com/questions/758502/can-multiple-versions-of-the-same-package-co-exist-on-the-same-system
  • And https://bbs.archlinux.org/viewtopic.php?id=295791
• One pharo-[pharo version] package: a virtual package depending on the stable VM for that pharo version (somehow a reification of this table: https://github.com/pharo-project/pharo-vm/wiki/Versions,-Builds-and-Branches). This package will be versionned using the Pharo release version numbers.
• One pharo-[pharo version]-ide: package: a virtual package depending on pharo-[pharo version] and any IDE specific dependencies (think SDL). This package will be versionned using the Pharo release version numbers.

I'll move this to the wiki to store it in a more friendly place

Ask Ubuntu

Can multiple versions of the same package co-exist on the same system?

In order to install tmux 2.1, I needed to install libtinfo5 version 6, I did this by downloading a .deb archive containing libtinfo5 and installing directly with command:

sudo dpkg -i libtinfo5_6.0+

How to install multiple versions of the same aur package / AUR Issues, Discussion & PKGBUILD Requests / Arch Linux Forums

GitHub

Versions, Builds and Branches

This is the VM used by Pharo. Contribute to pharo-project/pharo-vm development by creating an account on GitHub.

[noha]

I don't think having multiple packages pharo-vm-[major]-[minor] Is a good idea. Even if you use different names there is still the constraint that two packages cannot install files in the same place. Which is obvious to see. So each package needs to use different location of files which makes the need arise to discover the right vm to start. How is this to be done? How could start scripts like for the launcher etc. then use a pharo-vm? There is update-alternatives in debian for something like that and most likely comparable things in other distributions. This sounds like you thought about it top-down trying to solve a problem (which?) and I think it produces more problems than it solves.

And please for the pharo-[version] package do not depend on the stable, meaning a single version. That is usually also causing trouble. The table of image to vm mapping should be added exactly that way. The package management supports ranges of versions. So pharo-12 can depend on version version 10.0 to 12.x. If you don't make it it might clash when a pharo vm is pinned to a certain version.

[astares]

I don't think having multiple packages pharo-vm-[major]-[minor] Is a good idea...

Agree with @noha here. This can easily cause trouble.

[guillep]

Hi,

I don't understand your issues. Would you mind clarifying them?
My two cents:

• Different packages are installed in different directories, with different launching scripts (pharo-vm-10.3, pharo-vm-11.4)
• then symlinks or update-alternatives can be used to manage those if you want
• I'm not against using version ranges, I think nobody is
• package managers allow you to downgrade a package to an older version if needed

About the launcher, we don't look for "automatic discovery". A simple configuration file would be good enough (and even allow people to add their self-compiled VMs).

Unfortunately, what I read in your message is "I'm against, it's a problem and you're wrong but I'll not give you good arguments". Would you mind explaining better your stand point? We are not against refining this (this is very early stage, not carved in stone), so if you are concrete we can introduce concrete feedback.

[astares]

@guillep Just for me to understand and that I do not misinterpret:

• so for example a version "10.3.3" VM would be in one directory while a "10.3.4" in another, right?
• so a "10.3.4" release would not mean a hotfix for 10.3 as a replacement but still always as parallel installation, right?

If one requires an compatible working and "floating" 10.3.x line it would mean to symlink to the one required in that situation and switch when necessary.

Or do you mean to only have major minor in the future - that means you go with 10.5 in one directory and 10.6 in another
while you can have several packages for 10.5 like 10.5.1, 10.5.2, ... and several for 10.6. like 10.6.1., 10.6.2, 10.6.3, ...?
If a 10.6.2 is created it overrides the content of old VM package 10.6.1 in the 10.6 directory?

Maybe you can give concrete examples so it is better to see

[noha]

Hi guille,

not sure why you read it so negative. I might not be fully clear enough. Let's try to improve

Hi,

I don't understand your issues. Would you mind clarifying them?

My two cents:

• Different packages are installed in different directories, with different launching scripts (pharo-vm-10.3, pharo-vm-11.4)

yes, that's what I wrote and with that you have multiple directories that make it not obvious which vm is to be used.
And I didn't read anything why you want to have multiple vms on the same machine. So at that stage I cannot see the benefits but the drawbacks

• then symlinks or update-alternatives can be used to manage those if you want

Maybe that was a wrong assumption. I assumed you don't want to support all of these systems on top

• I'm not against using version ranges, I think nobody is

• package managers allow you to downgrade a package to an older version if needed

About the launcher, we don't look for "automatic discovery". A simple configuration file would be good enough (and even allow people to add their self-compiled VMs).

Does it mean you will always have to adjust a configuration file before being able to use pharo. My only concern is that there is no canonical path under which I will find a vm

Unfortunately, what I read in your message is "I'm against, it's a problem and you're wrong but I'll not give you good arguments". Would you mind explaining better your stand point? We are not against refining this (this is very early stage, not carved in stone), so if you are concrete we can introduce concrete feedback.

As I said I don't get where you read it that way. Hope it is a bit clearer now.

[guillep]

@guillep Just for me to understand and that I do not misinterpret:

* so for example a version "10.3.3" VM would be in one directory while a "10.3.4" in another, right?

* so a "10.3.4" release would **not mean** a hotfix for 10.3 **as a replacement but** still always as **parallel** installation, right?

If one requires an compatible working and "floating" 10.3.x line it would mean to symlink to the one required in that situation and switch when necessary.

Or do you mean to only have major minor in the future - that means you go with 10.5 in one directory and 10.6 in another while you can have several packages for 10.5 like 10.5.1, 10.5.2, ... and several for 10.6. like 10.6.1., 10.6.2, 10.6.3, ...? If a 10.6.2 is created it overrides the content of old VM package 10.6.1 in the 10.6 directory?

Maybe you can give concrete examples so it is better to see

Hi @astares

Only major-minor versions are packages, not patch.

10.3
10.4
11.2

Each major-minor version of the VM will have its own package and be installed separately (different binaries in different directories).

Patch versions will be package versions (Similar to how gcc does it in OBS too).
So this means that there will be for example the package:

pharo-vm-10.3

that has versions:

v10.3.1, v10.3.2, v10.3.3

If you want to change the version of one of those package, you can do as follows for example

https://askubuntu.com/questions/428772/how-to-install-specific-version-of-some-package

If we publish a hotfix/patch version for pharo-vm-10.3, let's say version 10.3.4, you will be able to update it through apt upgrade

Ask Ubuntu

How to install specific version of some package?

My questions are divided into two parts: How to know the version of installed package? How to install a specific package version?

[guillep]

• Different packages are installed in different directories, with different launching scripts (pharo-vm-10.3, pharo-vm-11.4)

yes, that's what I wrote and with that you have multiple directories that make it not obvious which vm is to be used. And I didn't read anything why you want to have multiple vms on the same machine. So at that stage I cannot see the benefits but the drawbacks

Because that's what the launcher requires :)

Let's say you want to launch Pharo 9, or that Pharo14 needs an incompatible VM, you need different versions of the VMs.

• Pharo9 VM (old)
• Pharo10.x VM to launch Pharo 11,12,13
• Pharo11 VM to launch Pharo14

We managed to keep a backwards compatible VM so far thankfully, but that may not always the case.
And best case scenario (in which we can), then there will be a single package and that's all ^^.

• then symlinks or update-alternatives can be used to manage those if you want

Maybe that was a wrong assumption. I assumed you don't want to support all of these systems on top

I'm not against any of these personally, I don't think anybody in the team is.
On the contrary, if we can leverage existing tools, we are happy.

• I'm not against using version ranges, I think nobody is
• package managers allow you to downgrade a package to an older version if needed

About the launcher, we don't look for "automatic discovery". A simple configuration file would be good enough (and even allow people to add their self-compiled VMs).

Does it mean you will always have to adjust a configuration file before being able to use pharo.

The launcher is a problem on itself.
The way VMs are installed right now by the launcher is not very linux friendly, downloading a binary that maybe works.
We are looking at making a pharo-launcher package that depends on the required VM packages.
But this is not yet fixed.

Regarding files, the launcher already supports configuration files to configure custom image sources besides the ones provided by the launcher.
Extending this to manage images should not be difficult. The launcher package can come with the file in question and updating it should be upgrading the launcher package...

My only concern is that there is no canonical path under which I will find a vm

Well, as explained above, we would like to have the capability of having different VMs side by side because of the launcher.

But! I think I get what you say is a problem, and I wonder what would be the best solution.
I don't have a strong opinion personally.

Maybe instead of having pharo-[version] virtual packages could be replaced by update-alternatives?
I wonder how widely available that is.

The build process could also automatically configure the packages as an alternative using update-alternatives, right?

Unfortunately, what I read in your message is "I'm against, it's a problem and you're wrong but I'll not give you good arguments". Would you mind explaining better your stand point? We are not against refining this (this is very early stage, not carved in stone), so if you are concrete we can introduce concrete feedback.

As I said I don't get where you read it that way. Hope it is a bit clearer now.

It's not a problem, it was just very difficult for me understanding what was the underlying issue that motivated the comment above.

I hope we can build from here, thanks!