Krikri::PluginHelpers::RpmPackage

os-release IDs Ansible's distribution facts map to the Debian family (the only family whose pkg_mgr override the dnf action's fetch can hit in practice, besides RedHat's own _check_rh_versions below).

list: - Ansible's exit_json(msg="", results=results) carries no changed, so the CONTROLLER backfills it after failed; dnf4 passes no rc at all, dnf5 passes rc=0 (both observed live, in this order, on their respective hosts).

ansible-core 2.19.11 registered-result shapes for the dnf-family backends (each observed through {{ r | to_json }} on a registered task - fedora:41 container for dnf5, Rocky Linux 9 for dnf, one FRESH host per engine so both engines saw identical host state):

The dnf: ACTION plugin dispatches on the host's pkg_mgr fact (or an explicit use_backend), so the SAME task registers a DIFFERENT key order per backend:

• dnf4 (Rocky 9, dnf.py): the module's own response dict, initialized msg/changed/results/rc and exited via exit_json(**response): msg, changed, results, rc, failed - msg "Nothing to do" on a no-op, "" on a real transaction, results holding "Installed: <nevra>" / "Removed: <nevra>" entries.
• dnf5 (Fedora 41, dnf5.py): a literal exit_json(results=, changed=, msg=, rc=) call, so THAT path keeps the kwargs order: results, changed, msg, rc, failed. update_cache only is a literal exit_json(msg=, changed=, results=, rc=) call on BOTH backends, so that path keeps the module's kwargs order: msg, changed, results, rc, failed - msg "Cache updated". list: (list_items' exit_json(msg="", results=results); dnf5 adds rc=0): msg, results[, rc], with changed backfilled by the CONTROLLER after failed. failure (failure_response = msg/failures/results/rc): msg, failures, results, rc, failed.

ansible_facts and warnings also appear in Ansible's registered result (the interpreter-discovery warning and the fact the controller merges in) but have no krikri equivalent - same as every other plugin pinned in this sweep.

The 2.21 dnf module's blanket-handler failure order (see unknown_error_failure): msg, results and rc from the embedded script's own dict, changed from the module wrapper and failed from the controller - with no failures key, which the wrapper only forwards when the list is non-empty (issue #932).

pkg_mgr.py's PKG_MGRS scan list (absolute paths only, which is why which-style probes diverged from the fact elsewhere - see package.cr's own detection note) - LAST existing entry wins, the collector loop keeps overwriting.

Real's dnf: ACTION plugin fetches the pkg_mgr fact on demand for a fact-less host (gather_facts: false) and puts it on the RESULT, so the registered task carries ansible_facts: {pkg_mgr: <backend>} - issue #844's registered r had exactly that, and a task that only checks r.results | length > 0 is unaffected by it but any r.ansible_facts.pkg_mgr reference is. A task that pinned the backend itself (use_backend:) never runs that fetch in real, and a module result that ships its own ansible_facts (interpreter discovery) replaces the action plugin's on the wire, so neither surfaces here.

A FAILED module result must not carry the fetched fact at all (issue #894): the module's own failure payload - which in real carries either the interpreter-discovery fact or nothing once discovery has already run - replaces whatever the action attached, so real's failed results never show pkg_mgr (live-verified vs 2.15.13 on Rocky 9: the failed "Unsupported parameters" result shows {"discovered_interpreter_python": ...} or no ansible_facts key at all). The backend-resolution tuple failure keeps its own ansible_facts - real's action-level fatal carries it (#768).

The package-manager command each includer shells out to ("yum" / "dnf"). Defined by the including plugin class.

True when pkg_mgr_fact came from a probe on the target, i.e. the fetch real's action plugin would have performed.