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 puppet-dev+unsubscr...@googlegroups.com. 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.
