From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonatan Schlag To: development@lists.ipfire.org Subject: Re: [PATCH 0/3] Pakfile metadata enhancements Date: Wed, 12 May 2021 20:45:53 +0200 Message-ID: <7EFFE588-57B9-4B00-8967-F1883CA98B7E@ipfire.org> In-Reply-To: <20210423161534.32738-1-robin.roevens@disroot.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3016371875926264695==" List-Id: --===============3016371875926264695== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > Am 23.04.2021 um 18:16 schrieb Robin Roevens : >=20 > =EF=BB=BFHi folks >=20 > During my discussion with Michael in the zabbix_agentd patchset thread > about knowing what addon services should be running or not, it came up=20 > that it would be handy for several reasons if we had a bit more metadata=20 > for pak-files as we currently have. Mostly knowing which services=20 > (initscripts) are installed by a pak-file. > This would allow for services.cgi to not have to manually try to find > out if an installed addon actually has an initscript or not. > Also paks like libvirt install 2 initscripts, those can now both be > displayed on the services.cgi page. > Idem for monitoring agents, which was my main objective. >=20 > So here is an attempt to achieve this. This is not yet a patchset to=20 > be applied yet, but rather a proposal as this change would require all=20 > addon LFS-files to be changed. But I didn't want to do that yet as=20 > this patchset may very wel be rejected completely :-). > The first patch introduces 2 new macro's: So it could be done in two separate patches or even better patch sets. Makes = reviewing easier and patches shorter :-) > - SUMMARY for a short, one-line summary of the package > - INITSCRIPTS for a space seperated list of initscripts provided by the > package. How it is supposed to be handled when a package (like libvirt) install its ow= n init scripts? So not a initscript we have in our source, but which is deliv= ered in the source of the package itself. If we put this in the list, the mac= ro will break. If we leave it out we lose information. Do you did some research how other distribution handle this problem? ( If the= y handle it at all.) Another approach which comes to my mind: Why not parsing the root file for /etc/rc.d/init.d/ (I currently do not know = if it is the right path)? So trying to detect which initscripts are part of t= he root file? > And an alternative INSTALL_INITSCRIPTS method instead of the current > INSTALL_INITSCRIPT method. As we now have all initscripts in the > INITSCRIPTS macro, the INSTALL_INITSCRIPTS will install all initscripts > listed in that macro, so a simple call to INSTALL_INITSCRIPTS will now > do the job instead of multiple calls in case of multiple initscripts > (for example libvirt. I noticed clamav actually uses 1 initscript for > starting 2 services, this could maybe also be split up again) > I included 2 examples in the first patch: libvirt and zabbix_agentd. But > when implemented ofcourse all makefiles should be updated.=20 >=20 > During the pak packaging process in the build procedure, those new > macro's will be inheritted in the generated pakfire meta-* files. >=20 > The second patch adds an extra 'info ' commandline parameter to > pakfire, which will in turn call a new Pakfire::pakinfo function. > This function wil parse the meta-* file of the requested pak and > functions in 2 modes:=20 > - "latest" which is the behaviour of the info parameter. This will=20 > display the latest available metadata of the pak and the status of=20 > the pak on the system as in: is it installed?, and if so, is it=20 > up-to-date. > - "installed" wich will display only information about the currently > installed pak and bail out of the requested pak is not currently > installed. > This function was added to provide a 'central' point/method to get pak > information. I don't know if there are other scripts beside services.cgi > that currently try parsing meta-* files. But they should then be changed=20 > to use this function instead. >=20 > Example output of the new pakfire info command: `pakfire info zabbix_agentd= `: > when installed and up-to-date: > --- > Name: zabbix_agentd > Version: 4.2.6-4 > Summary: Zabbix Agent > Size: 250.00 KB > Dependencies:=20 > Pakfile: zabbix_agentd-4.2.6-4.ipfire > InitScripts: zabbix_agentd > Installed: Yes > Status: up-to-date > --- > When an update is available: > --- > Name: zabbix_agentd > Version: 5.0.10-5 > Summary: Zabbix Agent > Size: 276.00 KB > Dependencies: fping > Pakfile: zabbix_agentd-5.0.10-5.ipfire > InitScripts: zabbix_agentd > Installed: Yes > Status: outdated (version 4.2.6-4 is installed) > --- > Or when a pak was discontinued and no longer supplied by ipfire, but > still installed on the system: > --- > Name: zabbix_agentd > Version: - > Summary: Zabbix Agent > Size: 250.00 KB > Dependencies: > Pakfile: zabbix_agentd-4.2.6-4.ipfire > InitScripts: zabbix_agentd > Installed: Yes > Status: obsolete (version 4.2.6-4 is installed) > --- > and at last when a pak is available, but not installed: > --- > Name: zabbix_agentd > Version: 5.0.10-5 > Summary: Zabbix Agent > Size: 276.00 KB > Dependencies: fping > Pakfile: zabbix_agentd-5.0.10-5.ipfire > InitScripts: zabbix_agentd > Installed: No > Status: not installed > --- >=20 > And then the last patch is an update of service.cgi now using the new > Pakfire::pakinfo function in "installed"-mode. >=20 > If there are any suggestions on more metadata.. I think this is the > moment to throw them at me. > And ofcourse suggestions/comments are welcome as this is currently only > a proposal for change. But I think we win in robustness of services.cgi > and user experience in both using pakfire and ability to provide > available services to monitoring agents. Just want to say thank you for taking this way, which might be =E2=80=9Charde= r=E2=80=9D but yields better result from my experience. Please do not take my= points as =E2=80=9Cthis is not right=E2=80=9D, more like =E2=80=9Cthere migh= t me other ways, are they better?=E2=80=9D. Greetings Jonatan=20 > On top of that could the whole meta-* files system be overhauled in the > future, if wanted, with only pakfire itself needing change as the rest=20 > will then depend on pakfire for correctly parsing it's "database". >=20 >=20 > Regards > Robin >=20 >=20 >=20 > --=20 > Dit bericht is gescanned op virussen en andere gevaarlijke > inhoud door MailScanner en lijkt schoon te zijn. >=20 --===============3016371875926264695==--