Exercise 2: Ansible's Generic Package Module Across Three Different Distros — Possible Solution
====================================================================

WHY ONE TASK WORKS ACROSS ALL THREE MACHINES
------------------------------
Per this chapter, "Ansible's ansible.builtin.package module detects
whichever package manager is actually present on a target host and
calls it automatically - the exact differences this whole chapter just
catalogued, abstracted away behind one generic interface." Rather than
the playbook author needing to write separate tasks calling apt on
Debian, dnf on Fedora, and apk on Alpine, the single generic package
task inspects each target host, determines which package manager that
specific host actually has, and issues the equivalent install command
for that manager automatically.

WHY THIS IS SPECIFICALLY POSSIBLE HERE
------------------------------
This chapter's own compare-table already showed that installing a
package is conceptually the same operation everywhere - only the exact
command differs (apt install, dnf install, apk add, and so on). Since
the underlying task ("install this package by name") is identical
across all four package managers, a single abstraction sitting on top
of all of them can translate that one generic request into whichever
specific command applies to each target.

THE REAL LIMITATION THIS CONVENIENCE COMES WITH
------------------------------
Per this chapter, "this generic module only supports the lowest common
denominator across all four - install/remove/ensure-latest by name.
Anything more specific to one package manager (an Arch AUR helper, a
Fedora module stream) still requires that manager's own dedicated
Ansible module rather than the generic one." The generic module can
only express what all four package managers have in common - it has no
way to represent a capability unique to just one of them, since doing
so would break the abstraction for every other target that lacks that
specific manager.

WHY THIS TRADE-OFF MAKES SENSE
------------------------------
The generic module trades specialized capability for portability -
exactly the right choice for simple, common tasks (installing a named
package) across a mixed fleet of different distros, but the wrong tool
once a playbook genuinely needs to do something only one specific
package manager supports.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the detection-and-translation mechanism behind the generic
module's cross-distro behavior using this chapter's own wording, and
names the specific limitation (lowest-common-denominator functionality
only) this chapter identifies as the real cost of that convenience.