Puppet Software Collections

Note: This is a proposal, not yet validated by the SIG.

1. Puppet 4

In order to:

• provide Consistency accross CentOS versions
• Not conflict with OS/epel packages (cmake, ruby, yamlcpp)

I think we should build a Software Collection to maintain the Puppet 4 packages.

1.1. Questions

Why is a SCL needed?

• Cfacter requires at build-time cmake3
• It also requires yamlccp which is in EPEL. We do not want to rely on EPEL or depend on upgrades they could do to the library so we probably want to recompile that in a SCL

Should we build the software collection on top of the Ruby 2.0.0 or 2.2.0?

• The best would be to have a Ruby 2.1 SCl because that is what upstram provides in their packages so we can be confident that the custom resource types and providers written by 3rd party providers will be fine.
• If not then 2.0.0 should technically be good enough, but then would we need that for el7 also?

Should we name the SCL puppet43 puppet4 puppet SCL?

The ideal would be to have the SCL named puppet-pc1 because pc1 is the identifier used by upstream project to identify the puppet 4 release. We could ensure that the content of the SCL == the Repository == The content of the upstream repository.

What would be the path of the SCL?

I think that it should then be /opt/centos/puppet-pc1, /etc/opt/centos/puppet-pc1, /var/opt/centos/puppet-pc1

Should we provide a puppet4 command in the default $PATH?

• I would like to
• Upstream does not do it