From the user side no functional changes. What this can do
now is decide whether to update or do a release type transition.
In most cases it is safer to get all updates first and then
do a release type transition afterwards. This can follow when
firmware type install can be shelved.
The former is so we have the date of the install point, not the
date of the package build time. And, secondly, if we loop the
argument for check through the JSON we know to put the result
into perspective later on.
Removed more fluff, concepts anf functionality are there.
Plugin conflict labels could probably require improvement,
but the way they work is relatively complicated, but maybe
it is only getting late.
As soon as we have plugin JSON metadata we can ship the
plugin conflict rework as well as that seems to help a lot
when recovering from strange situations (mostly development
things, but we never know).
Type "s" for security audit, or "h" for health audit.
We don't add it to the option prompt to not clutter the menu flow.
This is mostly for debug and development purposes.
We need the matching mirror version for the plugins to install so
simply block the update and let the user update first (instead of
only checking for updates and then installing later versions of
plugins).
This was a larger problem in past years but it is good practice to
require an up-to-date system anyway.
Looks like on the running system and in the build system the values
are static but obviously going from build to running system the
regenerate causes the checksums to shift. Not a security issue for
the "man" page databadse so better to hide these files from the
audit to avoid confusion and questions.
PR: https://forum.opnsense.org/index.php?topic=18484.0
Since the health check complains about a lot of different things
and opnsense-revert can repair most of it it is only fair to offer
this fix through GUI reinstall buttons via opnsense-revert for
an overly pleasing UX.
