As correctly pointed out by @rrhuffy, restricting update intervals to
minutes is pretty arbitrary. Therefore, change logic to specify updates
intervals in *seconds*.
Also, to maintain backwards compatibility for users that already have
custom intervals in their config, allow a module to specify their own
"factor" for intervals. So a module that expects the interval to be in
minutes can set the factor to 60.
Use generic interval mechanism in most of the modules that use slow
updates.
Only exception: getcrypto, as the interval is specified in seconds there
and I want to retain backwards-compatibility.
fixes#220
This is going to be a bit more comprehensive than anticipated. In order
to cleanly refactor the core and the engine, basically start from
scratch with the implementation.
Goals:
* Test coverage
* Maintain backwards compatibility with module interface as much as
possible (but still make modules easier to code)
* Simplicity
see #23
Hide alias concept for modules in the engine. That way, the individual
modules never get to know about whether a module has been aliased or
not.
see #23
Yet another bug in the DNF module - really a troublesome one. Only call
the dnf updateinfo every interval, not every second. That significantly
reduces CPU load.
Due to name-clashing of the datetime module's "time" alias, time.sleep
didn't work (as it was looked up from the i3bumblebee module),
consequently, the DNF poll thread exited.
While at it, "beautify" the thread cancelling a bit by waiting until
the main thread is not running anymore.
Pass the "output" object to the modules' constructor to allow them to
define their own callbacks.
Any user-provided callbacks take precedence and override those of the
module.
Add a module that periodically (by default, once every 30min) calls
"dnf updateinfo" and evaluates the results to report the number of
bugfixes, enhancements, etc.
If there's either too many pending updates, or at least one security
update, the module goes critical.
