We have to see how this holds up in practice. Reinstall was considered
as well for further protection but that might be even trickier depending
on what locking and version tricks the user did to their install to
retain a particular (working) state.
While testing pkg was snatched from FreeBSD mirror, which isn't
advisable (nevermind that FreeBSD mirror was enabled in the first
place).
Do the same for the release type shift to avoid pivoting towards
third party repos for any reason whatsoever.
This way the build can do all sorts of funny things and we will end up
with a consistent config.xml after boot. For people restoring other
config.xml that is not the case but in this scenario the user is likely
aware of what he or she is doing.
o Do not load the text changelog for the GUI as it is unused
o Rename product_name to product_id for consistency
o Always hint at product_target so correct changelog is displayed
o Rename type to target for consistency
o Add distinguishable labels to changelog view actions
o Return JSON when argument is given for easier debug
It's probably better to chown the error pages directory, just like we for other squid related directories, to prevent ownership issues. Although this doesn't seem to go wrong, the files are intended for squid.
closes https://github.com/opnsense/core/issues/4703
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.
