From: Robin Roevens <robin.roevens@disroot.org>
To: development@lists.ipfire.org
Subject: group call for review/opinions/idea's (was: [PATCH 0/3] Pakfile metadata enhancements)
Date: Tue, 11 May 2021 21:30:15 +0200 [thread overview]
Message-ID: <029dd8fc036a4f26a19b84b5654a150791bac8cd.camel@disroot.org> (raw)
In-Reply-To: <20210423161534.32738-1-robin.roevens@disroot.org>
[-- Attachment #1: Type: text/plain, Size: 5306 bytes --]
A gentle reminder to the group, please check out this proposal for
adding and consulting extra metadata to paks, and comment on it, maybe
suggest other metadata besides initscripts and summary that I
implemented in this proposal patch-set, that could be handy for other
addons or cgi pages or just plain info to the user...
Thanks..
Robin
Robin Roevens schreef op vr 23-04-2021 om 18:15 [+0200]:
> Hi folks
>
> During my discussion with Michael in the zabbix_agentd patchset
> thread
> about knowing what addon services should be running or not, it came
> up
> that it would be handy for several reasons if we had a bit more
> metadata
> for pak-files as we currently have. Mostly knowing which services
> (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.
>
> So here is an attempt to achieve this. This is not yet a patchset to
> be applied yet, but rather a proposal as this change would require
> all
> addon LFS-files to be changed. But I didn't want to do that yet as
> this patchset may very wel be rejected completely :-).
>
> The first patch introduces 2 new macro's:
> - SUMMARY for a short, one-line summary of the package
> - INITSCRIPTS for a space seperated list of initscripts provided by
> the
> package.
> 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.
>
> During the pak packaging process in the build procedure, those new
> macro's will be inheritted in the generated pakfire meta-* files.
>
> The second patch adds an extra 'info <pak(s)>' 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:
> - "latest" which is the behaviour of the info parameter. This will
> display the latest available metadata of the pak and the status of
> the pak on the system as in: is it installed?, and if so, is it
> 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
> to use this function instead.
>
> 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:
> 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
> ---
>
> And then the last patch is an update of service.cgi now using the new
> Pakfire::pakinfo function in "installed"-mode.
>
> 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.
> 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
> will then depend on pakfire for correctly parsing it's "database".
>
>
> Regards
> Robin
>
>
>
--
Dit bericht is gescanned op virussen en andere gevaarlijke
inhoud door MailScanner en lijkt schoon te zijn.
next prev parent reply other threads:[~2021-05-11 19:30 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-23 16:15 [PATCH 0/3] Pakfile metadata enhancements Robin Roevens
2021-04-23 16:15 ` [PATCH 1/3] buildprocess: Add extra metadata to meta-* files Robin Roevens
2021-05-12 18:49 ` Jonatan Schlag
2021-05-14 12:24 ` Michael Tremer
2021-05-14 20:07 ` Robin Roevens
2021-05-18 15:09 ` Michael Tremer
2021-05-24 20:23 ` Robin Roevens
2021-06-06 18:41 ` Robin Roevens
2021-06-10 11:27 ` Michael Tremer
2021-06-17 22:28 ` Robin Roevens
2021-06-18 8:32 ` Michael Tremer
2021-06-10 11:24 ` Michael Tremer
2021-05-14 12:23 ` Michael Tremer
2021-05-14 20:16 ` Robin Roevens
2021-05-18 11:12 ` Michael Tremer
2021-04-23 16:15 ` [PATCH 2/3] pakfire: add 'info <pak(s)>' option Robin Roevens
2021-05-13 8:02 ` Jonatan Schlag
2021-05-13 19:11 ` Robin Roevens
2021-05-14 12:19 ` Michael Tremer
2021-05-14 20:24 ` Robin Roevens
2021-05-25 11:22 ` Michael Tremer
2021-04-23 16:15 ` [PATCH 3/3] services.cgi: use new Pakfire::pakinfo function Robin Roevens
2021-05-11 19:30 ` Robin Roevens [this message]
2021-05-12 18:45 ` [PATCH 0/3] Pakfile metadata enhancements Jonatan Schlag
2021-05-12 22:31 ` Robin Roevens
2021-05-15 12:10 ` Adolf Belka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=029dd8fc036a4f26a19b84b5654a150791bac8cd.camel@disroot.org \
--to=robin.roevens@disroot.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox