Hi Gert, On Mon, 09 Jan 2023, Gert Doering wrote: > So don't do OS updates. But *do* update the probe software, automatically, > and in normal intervals.
writing while wearing my hat as a RPM packager: I'm not really sure how this shall work practically: If the probe software is run on regular (non- hardware probe) systems, there are runtime dependencies to other software, e.g. due to dynamic linking. Latter is encouraged by Linux distributions, but might lead to the risk that a software probe update either installs a new dependency (installs a new package) or updates a dependency due to e.g. a ABI soversion bump. And an updated package can cause new issues to other packages or software, especially on a poorly to not maintained system (I assume here that a system that doesn't get software probe updates doesn't get much updates at all). In the end, > I'm very much of the opinion that upgrades should not be an opt-in service, > *and not even an opt-out*. As much as I would like to see an always up-to-date software probe, I can not think of a way conform to e.g. Fedora/EPEL packaging policies. Updates of a package can not be enforced or triggered by the package itself. Other ways would be user-written cronjobs/systemd.timers or administrators using yum-updatesd/dnf-automatic - but that's nothing a RPM package in Fedora/ EPEL is allowed to influence/configure/change during its own installation. My suggestion is to provide documentation how system administrators who set up software probes can easily configure automatic system updates. But these are practically often disliked by administrators (from my point of view). Regards, Robert
pgptDUTpLQFkj.pgp
Description: PGP signature
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
