On Mon, Jun 22, 2015 at 10:22 PM, Michael Stahnke <stahnma@xxxxxxxxxxxxxx> 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
