Cannot install older openhab versions from repository

[dwrobel]

Page https://v34.openhab.org/download/ allows you to install version openhab 3.4, however it seems that both DEB and RPM repositories are identical with version 4.x (see e.g. baseurl in RPM baseurl=https://openhab.jfrog.io/artifactory/openhab-linuxpkg-rpm/stable).

BTW, the same issue applies for 2.x series in the https://v2.openhab.org/download/.

[BClark09]

Thanks @dwrobel,

You should be able to install older versions either by using the apt, yum or dnf version option (e.g. apt install openhab=3.4.5-1), or by downloading the package installer file directly (e.g. for RPM: from https://openhab.jfrog.io/ui/native/openhab-linuxpkg-rpm/stable/). The baseurls for 2, 3 and 4 are the same.

@openhab/foundation-staff (I'm hoping this is the correct ping based on the team description): How do we go about changing the archive version installation notes of websites?

[dwrobel]

You should be able to install older versions either by using the apt, yum or dnf version

I'm not sure about apt but it won't work for yum/dnf. Even if you install old version using full URL, then on the next run yum/dnf will update the package to the latest version from the repository.

So, the options would be: (a) rename the latest openhab 3.x to openhab3 (the same would apply for openhab-addons), (b) for version 3.x don't mention about the repository (at least for yum/dnf) only provide full URL for the package.

(a) option would be more preferred as this would let people to install either: openhab2, openhab3 or openhab package and keep updates working fine. As of now only openhab 3.x is broken using repository, at least for yum/dnf based distros.

[BClark09]

Thanks @dwrobel, I now see what you mean.

It used to be the way you mention, but the decision was made to name the package openhab after the move from 2.x to 3.x. The number of breaking changes and the availability of Java 17 has caused some issue, particularly with people who accidentality update.

I think an option (c) (based off a) would be be best, that is: Create and serve virtual packages named openhab3 and openhab4 which depend on strict version strings. openhab3 would depend on versions <4.0.0 for example.

In the meantime, have you considered using something like dnf versionlock https://dnf-plugins-core.readthedocs.io/en/latest/versionlock.html?

[mstormi]

Hmm. As openHABian maintainer I have to deal with all the variants and implications of people to run OH version X from repo Y, wanting to upgrade or not OS packages but not OH, or OH only, Java yes or no, on bullseye, buster or even older setups. To be frank I dislike if not to say hate this proposal. This will massively increase the efforts needed on the forum (and sometimes github) to support people. Once there's multiple packages some will start using and it will lead to MUCH confusion, the existing release/milestone/snapshot taxonomy is already more than confusing to too many.

It'll mean a lot of additional efforts to maintain openHABian (alone that you have to determine what exactly a user installed is a huge time eating task in itself. Most just don't know or don't tell you right away). When the package name change was introduced with OH3, it was a NIGHTMARE for me to adjust openHABian and I'm still seeing negative effects of that today.

As there's working options for both, apt and dnf, to accomplish holding older versions, clearly we shouldn't change overall architecture, causing massive efforts just to provide some very few users a more comfortable version of a rarely needed option.

[dwrobel]

dnf versionlock

AFAIK it's for locking version and it doesn't let me install openhab version 3 from repository which contains version 3 and 4 - which was my original question.

Create and serve virtual packages named openhab3 and openhab4

Wouldn't it be simpler to just use openhab3, openhab4 and so on by default? Or use separate repositories for different major versions?

Some examples showing why keeping all versions in one repository doesn't work:

Example 1):

• you have a running setup with openhab package installed (at the time version 3 was the latest one),
• you cannot enable automatic updates because you have to manually inspect every update (dnf update) to avoid situation that openhab package will be updated to a new major version (e.g. from version 3 to version 4). You also cannot use lockversion because you're interested in updating openhab but still keeping the installed major version.

Example 2):

• you're managing your OS installation in a fully automated way using kickstart file and Ansible playbook for the rest of the system (including openhab).
• you deployed a working instance at the time the openhab version 3 was the latest one,
• your hardware broke you need to immediately re-deploy the openhab on new hardware, but currently the latest version is 4 - then your Ansible playbook is broken as it will install version 4 instead of 3.

For all aforementioned examples and similar having openhab3 openhab4 and so on (without any extra virtual overhead) will simply solve the problem. Of course, the same can be achieved by having separate repositories for different versions of openhab. But the former option will very likely generate less maintenance burden when hosted on jfrog.

@mstormi I'm interested how people with similar approach handles those scenarios effortlessly with apt.