What happens
get_dnf5_locks() returns an empty result when tomllib is unavailable:
if tomllib is None:
return [], [], []
tomllib is part of the standard library from Python 3.11 on, and the plugin
deliberately ships no backport. On an older interpreter the check therefore reports
"No version locks in place." and OK on a host whose /etc/dnf/versionlock.toml
holds packages back. Every other lock source of the plugin is plain text and keeps
working, so nothing in the output hints that one source was skipped.
An administrator reading OK concludes that no package is pinned. The next update
then leaves the locked packages behind, which is exactly the state the check exists
to surface.
Why it is narrow, and why it should still be fixed
The comment in the source states the assumption:
only dnf 5 keeps its locks in a TOML file, and every distribution that ships dnf 5
also ships a Python that has this module
That holds for the distributions shipping dnf 5 today, and the compiled packages
are built per distribution against that distribution's own Python. The gap opens
where the interpreter is not the system one: a source install into a virtualenv
built on an older Python, or a monitoring agent carrying its own interpreter.
The failure mode is what makes it worth fixing. A check that cannot read one of its
sources should say so, not report the absence of findings.
Suggested fix
Report the situation instead of returning empty. Not through the existing refused
channel, whose message reads "The package manager refuses N lock configurations, so
installing and upgrading fails on this host" - that is untrue here, the package
manager is fine and only the check cannot read the file. A separate message along
the lines of
/etc/dnf/versionlock.toml cannot be read, this needs Python 3.11 or newer
with WARN keeps it on the list of things to fix. UNKNOWN is defensible too, but
it hides the plain-text locks the check did read.
Only emit it when the file actually exists, so a host without dnf 5 stays quiet.
Reproducing
cd check-plugins/rpm-versionlock/unit-test
python3.9 ./run
Before the skip added in v7.0.0, seven testcases failed here with
Expected retc 1, got 0. The testcases that need a parsed TOML file are now
skipped on interpreters without tomllib (NEEDS_TOMLLIB in
check-plugins/rpm-versionlock/unit-test/run). Remove that skip as part of the
fix and let the testcases assert the reported message instead.
Sibling plugin
deb-versionlock is unaffected: APT keeps its holds in plain text and the plugin
parses no TOML.
What happens
get_dnf5_locks()returns an empty result whentomllibis unavailable:tomllibis part of the standard library from Python 3.11 on, and the plugindeliberately ships no backport. On an older interpreter the check therefore reports
"No version locks in place." and OK on a host whose
/etc/dnf/versionlock.tomlholds packages back. Every other lock source of the plugin is plain text and keeps
working, so nothing in the output hints that one source was skipped.
An administrator reading OK concludes that no package is pinned. The next update
then leaves the locked packages behind, which is exactly the state the check exists
to surface.
Why it is narrow, and why it should still be fixed
The comment in the source states the assumption:
That holds for the distributions shipping dnf 5 today, and the compiled packages
are built per distribution against that distribution's own Python. The gap opens
where the interpreter is not the system one: a source install into a virtualenv
built on an older Python, or a monitoring agent carrying its own interpreter.
The failure mode is what makes it worth fixing. A check that cannot read one of its
sources should say so, not report the absence of findings.
Suggested fix
Report the situation instead of returning empty. Not through the existing
refusedchannel, whose message reads "The package manager refuses N lock configurations, so
installing and upgrading fails on this host" - that is untrue here, the package
manager is fine and only the check cannot read the file. A separate message along
the lines of
with WARN keeps it on the list of things to fix. UNKNOWN is defensible too, but
it hides the plain-text locks the check did read.
Only emit it when the file actually exists, so a host without dnf 5 stays quiet.
Reproducing
cd check-plugins/rpm-versionlock/unit-test python3.9 ./runBefore the skip added in v7.0.0, seven testcases failed here with
Expected retc 1, got 0. The testcases that need a parsed TOML file are nowskipped on interpreters without
tomllib(NEEDS_TOMLLIBincheck-plugins/rpm-versionlock/unit-test/run). Remove that skip as part of thefix and let the testcases assert the reported message instead.
Sibling plugin
deb-versionlockis unaffected: APT keeps its holds in plain text and the pluginparses no TOML.