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.