On 11/18/2014 06:11 PM, Michael Stahnke wrote: > > On EL6.x, why not use a new SCL? Or even install into the existing > ruby193 SCL? > > > Part of the goal here is to have control of the ruby version. The SCL > offers one version of Ruby 1.9.3, Ubuntu offers another in their > distribution, as does Mac OS X, and the next OS. Compound that with > libssl fun and End of Life constraints on Ruby 1.9.3, and it's just > not that fun. (SCLs also have their own lifecycle that is different > than RHEL). > > We'll be picking one Ruby (2.1.z), and using that everywhere for a > consistent stack. I'm not unsympathetic to the desire to vendor a version of ruby but that doesn't prevent the creation of a new SCL with all PL vendored (is that a word?) packages in it. This is a primary use case for SCLs.
I'm a bit concerned about gems and other components accumulating in the path tree of an AIO that aren't tracked; I foresee upgrade 'fun'. I think it would be preferable to be able to package gems, report processing scripts, etc. into RPMs that install into a puppet SCL. Would facter be part of a puppet AIO? If so, would that mean it's no longer independently upgradable? How would you orchestrate agents installing gems that are needed by ruby facts? How would a puppet AIO affect mcollective? Would it be it's own AIO with independently vendored dependencies? How would mco agents be installed? -Josh -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/546CD8D6.8030903%40cpan.org. For more options, visit https://groups.google.com/d/optout.
