The ruby included with RedHat/CentOS-6 is of version 1.8.7, which is too old for many applications. Though simply updating it with a custom-built RPM is possible, my colleagues shy away from the idea and wish to use the rh-ruby22 packages available from the SCL-repo.
That installs ruby-2.2, which is great, but under /opt/rh/rh-ruby22
. I now need to install several gems and would like to, obviously, use Puppet:
package {'example':
ensure => '0.25',
provider => 'gem'
}
Unfortunately, the gem-provider invokes /usr/bin/gem
instead of /opt/rh/rh-ruby22/root/usr/bin/gem
that needs to be invoked. Is there any other way? Thanks!
The package resource, and in particular the gem provider, now supports the use of the
command
attribute. Your particular example is now supported like this:Ok, the "easy" way is to implement one's own package-provider. Fortunately, one can inherit everything from the existing gem-provider overriding only the gem-command itself.
Because SCL's rh-ruby22 is so retarded, you can't even invoke its
ruby
orgem
directly -- without settingLD_LIBRARY_PATH
first -- we create wrappers for them in/usr/bin
. The/usr/bin/gem2
, for example, sets the library path (andPATH
) and thenexec
s the real/opt/rh/rh-ruby22/root/usr/bin/gem
with its own arguments ("$@"
).My new provider uses the
gem2
wrapper script to do its thing.I created the file
gem2.rb
inmodules/SOMEMODULE/lib/puppet/provider/package/
with the following content (tested with Puppet-3.8.7):Though I was hoping, my implementation would allow one to specify the gem-command as a parameter in the puppet-manifest, it is impossible to do this without completely rewriting the existing gem-provider. My way is much easier and just as efficient.
As a bonus, copying the file to some other name (such as
gem19.rb
) will automatically create the new provider -- just be sure,gem19
is in the$PATH
.The module, under which you'll save this file, can be any module used by the machine(s) that need the new provider.