From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Packaging different Zabbix agent versions Date: Wed, 30 Oct 2024 09:54:36 +0000 Message-ID: <18510EFC-71F9-4DC1-9A27-EE21EAC6F8CB@ipfire.org> In-Reply-To: <3f55326f14a25ea68f1f6a374b018206d8f02481.camel@roevenslambrechts.be> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3092754770542066924==" List-Id: --===============3092754770542066924== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Robin, This is an interesting question to which I don=E2=80=99t have a very good ans= wer. > On 26 Oct 2024, at 23:08, Robin Roevens wrote: >=20 > Hi all >=20 > I would like to start releasing packages for Zabbix Agent 7.0 (new LTS) > as it offers some added value when used with Zabbix server 7.0 > (heartbeat, item-level custom timeouts, ...). > However, the agent is not backwards compatible. Hence, if I would > update the zabbix_agentd package to contain v7.0, people still running > Zabbix 6.0 LTS (still supported until feb. 2027) or even 6.2 or 6.4 > would then no longer be able to monitor IPFire. I consider this quite bad software design since it is causing some issues wit= h their user base and creates a lot more work for distributions to package tw= o of the same software. We also ready have a lot of different monitoring tool= s and occasionally people request more, so I assume that each of them have al= ready only a small user base as they divide the market - and now having two v= ersions of Zabbix is even further splitting the Zabbix user base so that I am= sure that for each version we will only have very few users, but still a lot= of work to package it. This is just for the record. It would be nicer if upstream would give us bett= er migration paths. > So it would be nice if we could provide both zabbix_agentd 6.0 and 7.0 > packages so users can choose depending on their Zabbix server version. > I think offering different versions of the same software is not yet > done before? Luckily this was not necessary, or in case of Icinga/Nagios there was a fork = that renamed the package so that there were no file conflicts. Pakfire in IPFire 2 was never supposed to be a full-blown package management = system and therefore it does not support conflicts like Pakfire in IPFire 3 d= oes. There, we would simply configure that those packages cannot be installed= at the same time and the package management system will take care of it. > How should I do this? Just add a new package zabbix_agentd7 next to the > current zabbix_agentd package? There is a way=E2=80=A6 but before, maybe it is worth to conduct a little sur= vey on community.ipfire.org to see if there ar= e actually any users who have a preference either way? I don=E2=80=99t know m= uch about Zabbix so I am not sure how fast people are with upgrading (I assum= e a single device in your infrastructure that does not support version 7 will= block you from moving everything forward?). > But if so: > - Can we then rename the zabbix_agentd pak to zabbix_agentd6 (I don't > immediately see how that should be handeled during upgrade?). > If not possible or feasable, that's not that big of a deal as in time > (feb 2027) that package can be removed and that "problem" then has > solved itself. So this is maybe just some unneeded hassle. We could rename it, that might make the whole thing a little bit cleaner. Either you can add the major release number or simply call it zabbix-agent-le= gacy? Whatever you fell is most appropriate. This change would have to be done in the core update though. > - Can we prevent users from installing both packages as they will > conflict? (both file-wise and used port-wise) Hmm, that will be a problem. Pakfire does not support conflicts. We can eithe= r add this (because to simply conflict with a name this might not be too hard= to do), or another version would be to actually build everything in such a w= ay that there are no real conflicts. Rename /usr/sbin/zabbix_agentd to /usr/s= bin/zabbix_agentd-7 and so on. There are install scripts that we have used before to stop the installation p= rocess, but those are being called *after* the files have been extracted so t= he formerly installed version will already have been overwritten. > - And what should I do with the IPFire specific customizations as they > will be identical for both packages.: > - Just duplicate them to both packages, (probably the easiest) > - or move them to yet another package Good question. It might be easiest to just copy things. Because then we can j= ust drop the older version whenever time is right and don=E2=80=99t have to m= erge packages together again. I hope this break is a one-off and version 8 wo= n=E2=80=99t do this again. > "zabbix_agentd_ipfire_extension".. And then let both agent packages > depend on that one. But that may be confusing to the user as that > package would require one of the then 2 zabbix_agentd packages to be of > any use, but we can't do a zabbix_agentd OR zabbix_agentd7 dependency, > I think? I would not be against it if you prefer this option. Technically it will work. > ... >=20 > Or should we just refrain from adding v7.0 for now.. and then probably > until 2027 or until ipfire3, (if pakfire there supports such packages > conflict/dependency mechanisms?).. but by then there probably is > already an 8.0 and possibly a 9.0.. Good question, maybe this is worth to investigate with the community if there= is demand for version 7 already. I don=E2=80=99t know how fast people will u= pgrade. Having said my thoughts from earlier, IPFire should not be the blocke= r why people cannot upgrade their entire infrastructure to version 7. Is there any reason that justifies this big break? -Michael > So... >=20 > I would like your thoughts about this ? >=20 > Robin --===============3092754770542066924==--