[silug]

Fixes #211.

openvox_bootstrap 1.8.0 adds manage_release_package to its install task (voxpupuli/puppet-openvox_bootstrap#78). So bootstrap::install_packages now always uses openvox_bootstrap::install with manage_release_package => $manage_repos. Before, it fell back to Bolt's package task when manage_repos was false.

• Pins openvox_bootstrap 1.8.0 in Boltdir/bolt-project.yaml and Boltdir/Puppetfile, and requires >= 1.8.0 in the bootstrap module's metadata. The spec fixtures already pull the latest from the Forge.
• I edited the Puppetfile by hand because bolt module install --force can't resolve the current pins. choria-mcollective 0.15.0 wants puppet-systemd < 10.0.0, but 11.0.0 is pinned. That conflict is already on production.
• Version handling is unchanged. Unset version becomes latest, as it already did with manage_repos, and the task leaves an installed agent alone.
• Debian/Ubuntu: with manage_release_package=false, the task doesn't run apt-get update. Neither did the package task fallback, so behaviour on those hosts is the same as before.

Testing

On fresh CentOS Stream 9 VMs, I added the OpenVox 9 repo by hand from the release RPM's contents, without installing openvox9-release, to simulate a Satellite. Then I ran basic_aio with manage_repos=false postgres_source=os and the rest of the demo's arguments:

• Every install ran openvox_bootstrap::install and logged "Not managing the release package; using the configured package repositories". The package task never ran.
• openvox9-release is still not installed on either host. openvox-agent, openvox-server, openvoxdb, openvoxdb-termini, and PostgreSQL 16 from the AppStream module are installed.
• A follow-up agent run on each host exited 0.

The acceptance workflow on this PR covers the default manage_repos=true path.

🤖 Generated with Claude Code