AIO vs. Puppet-only agent packages

[nmburgan]

Some people like the AIO package, some don't. Should we make both?

[ekohl]

I like the idea of non-AIO packages, but one complication is that even EL9 only ships Ruby 3.0 by default and that's too old for Puppet 8. That makes it hard in practice.

You can however think about what you vendor in. Today curl and openssl are vendored in and those regularly have CVEs. Perhaps it's possibly to have some middle ground where you use system libraries if they're recent enough but update what you need to. However, that is more work and creates a larger support matrix.

[ripienaar]

Some people like the AIO package, some don't. Should we make both?

The value from AIO is that it’s the only way :) I mean it’s not exactly great or anything, but it’s the same everywhere and that’s what makes it good.

[tuxmea]

Please keep AIO. Many orgs are OK with AIO.
Benefit of AIO:

• same versions for all OS (AIO vs. Puppet-only agent packages #12 (comment))
• use updated libraries on older non-EOL OS
• single package allows simple installation and removal
• non-disruptive installation and upgrade for existing users

If people prefer their local ruby and libraries, they can still make use of the Ruby Gem (as it is now).

[yakatz]

I have a strong preference for AIO because it makes sure that Puppet on every machine will run the same way.

I would be OK with a smaller package too as long as we can also package the dependencies just in case - I don't know if there is a good way for package managers to support this - for example, saying that we need certain versions of ruby and if they aren't available, install our vendored version. (We can't just say the vendor package provides ruby because that will break other packages.)

[dhs-rec]

I prefer the ones from the Debian repositories (non-AIO of course), because they

1. fit better into the distribution
2. are available for all Debian architectures

[ekohl]

I started puppetlabs/puppet#8636 a long time ago to better define run mode between the various deployments. It would clearly standardize where to expect files. In that PR it was also mentioned that it could help reduce patches on BSDs. Perhaps the various non-AIO/distro maintainers could come together and make a decision how to ship. This should also discuss package naming and what it provides (Debian doesn't ship all vendored modules by default today).

Overall I think post-fork we need to decide on which paths are used. /etc/puppetlabs and /opt/puppetlabs feel wrong to me.

[jcharaoui]

Debian doesn't ship all vendored modules by default today

FTR starting with the next Debian release (13, trixie), the vendored modules will be shipped as part of the puppet-agent package.

[jcharaoui]

Overall I think post-fork we need to decide on which paths are used. /etc/puppetlabs and /opt/puppetlabs feel wrong to me.

Indeed. Whatever the new paths that are chosen for OpenVox, please feel free to use this patch that we've been shipping in Debian as a basis: https://sources.debian.org/src/puppet-agent/8.10.0-5/debian/patches/0001-Adjust-default-paths.patch/

[jcharaoui]

I don't know if there is a good way for package managers to support this - for example, saying that we need certain versions of ruby and if they aren't available, install our vendored version.

I can only speak for Debian here, but you might be able to monkeywrench something like that into some post-installation script, but that would be frowned upon and certainly against policy and thus never accepted into the main Debian archive.

It seems to me like the limited energies might be better invested in providing solid AIO packages here, while making things easy for distro packagers like us who are interested in maintaining system-integrated packages.