Puppet 4

[Nico Kadel-Garcia]

On Mon, Jun 22, 2015 at 10:22 PM, Michael Stahnke
<stahnma at puppetlabs.com> wrote:
> As a point of moderation, we could probably break out the FHS/stateless
> discussion into its own thread, as at this point this has nearly nothing to
> do with Puppet.

Good point. Let me circle it back around:

It seems reasonable for a management toolkit like Puppet, which may
require somewhat non-system versions of critical libraries and
scripting language modules, to follow the FHS for third-party packages
and live in /opt/puppet. There's a real burden in relying on, and
integrating with, the Fedora system components due to the potential
for incompatible upgrades of those modules in the Fedora operating
system, or for leading edges of those components to be introduced for
Puppet but be incompatible with other, especially older, existing
Fedora systems. So it's sometimes safer, as in this case, to segregate
those components from the base OS.

So while as a recommended practice segregating tools like "Puppet" to
a separate working area can be non-standard for Fedora, it certainly
seems both workable and justified in this case. It helps retain
independent upgradeability across Fedora releases and for the RHEL
environments, the corporate supported OS which provides a great deal
of Fedora support and ingrastructure.

I've been through similar issues recently with chef, chefdk, RT,
cfengine, GForge, and other add-on components. The desire to root the
core of such a package in the operating system's own internal modules
and libraries is understandable, but it can become a maintenance and
integration nightmare  quite quickly and needs to be, occasionally,
rejected.