Multiple versions of package

For Developers
1

Hello,

Some projects support multiple releases at the same time, e.g. zabbix

Currently (2022-01-05), supported versions of zabbix are: 4.0(LTS), 5.0 (LTS), 5.4(non-LTS), 6.0 will be released in 2022Q1
4.0 will be supported till October 31, 2023
5.0 will be supported till May 31, 2025
5.4 will be supported tillFeb 28, 2022

so currently there are three official supported releases, but OpenWrt packages master branch has only one version (zabbix 5.0)

What should I do if I want to add zabbix5.4 or zabbix6.0 to OpenWrt packages? May I add new version as a new package? or I must replace current 5.0 version to newer one?

If I just replace zabbix5 with zabbix5.4 or zabbix6, then zabbix-proxy (installed on openwrt device) will not work with zabbix5-server (zabbix-proxy is totally incompatible between releases so I can't use zabbix-server 5.0 with zabbix-proxy 5.4). zabbix-agent - zabbix-server versions compatibility is much more better, but offically only backward-compatible (zabbix server 5.4 with zabbix agent 5.0 is officially supported, but the opposite configuration officially not supported)

Some users prefer LTS zabbix-server, some users prefer the newest so in ideal world OpenWrt should provide all currently supported versions to be compatible with different zabbix-server versions

The same story might be applicable to another projects, I just used zabbix as an example of multi-versions issue.

2

Disclaimer: I'm not an OpenWrt developer, nor related to the project in any capacity and haven't ever used zabbix, so feel free to ignore me.

Aside from most exceptional cases, there should always only be one version of a package in the archive at any given point in time. OpenWrt is made with heavily resource constrained devices in mind and has only a rather small number of developers, just as well as a very limited package manger that doesn't cope too well with more complex package relations, so it's important to keep things simple.

Flash size constraints aside, can you (reasonably) co-install different zabbix versions on the same system (think package 'a' depends on 4.0, package 'b' on 5.0, package 'c' on 5.4), if the answer is no - then it really is no.

How do package 'a' and 'c' work together (if that applies to the zabbix ecosystem), in all likelyness they can't - so no use to provide multiple versions at all.

Would you need multiple variants of 'plugin style' packages for the various major versions, if so - a huge heap of added complexity.

Are there cold hard reasons to provide multiple generations? Think of gtk2 --> gtk3 or python2 --> python3, which came with quite major API changes and weren't compatible with each other. If not, then don't do it (and keep in mind, OpenWrt itself didn't ship with both python2 and python3, but made a hard cut between them, so you'd want an even better reason).

Unless there are severe functional differences between the versions, I would try very hard to avoid shipping multiple versions at once. If it's more of a warm fuzzy feeling of 'stability' or preferring an LTS branded versions, then it's down to a judgement call of the maintainer which version to ship (evaluating the current state of the versions and their predicted support cycle relative to OpenWrt's own).

--
Leaf packages might get an easier pass, assuming nothing else depends on them.

3

"packages" repo (with packages like zabbix) is community maintained repo so "core" OpenWrt developers are not involved to packages that they don't use/want to help

I propose to create packages like zabbix50, zabbix54, zabbix60 so it is not requires to do opkg more complex, form opkg point of view it will be just different packages

packages like zabbix are stub so usually there is no package that depends on zabbix

Typical installation of zabbix is:

  1. You have zabbix-server deployed on general OS like ubuntu/rhel/etc on high-performance hardware/VMs with fast storage
  2. You have zabbix-agent on hosts you want to be monitored (that is typical case for using zabbix on OpenWrt low-end devices like soho routers)
  3. You have zabbix-proxy on hosts as a gateway to another network (that is also normal case to use zabbix on OpenWrt)

The issue that zabbix-proxy 5.0 doesn't work with zabbix-server 5.4 so if someone upgrades zabbix-server from 5.0 to 5.4 then it is not possible to use it with OpenWrt compiled from "packages" repo (currently OpenWrt has only 5.0 version). If we upgrade 5.0 to 5.4 in OpenWrt packages repo then everyone (who uses agent/proxy with OpenWrt) will be forced to upgrade their zabbix-server to 5.4 or install old (backuped) package version or maintain theirs own repo with an old version.