I got it installed in the end: 1) Only install dev libraries for the architecture you are using (gcc and mysql dev) 2) Gems from source (not RPM) were used 3) Active record can not be the latest version (down grade was required)
The only other option is to roll your own RPM or scavenge them from elsewhere on the net. As that can screw up the whole OS update I would avoid it unless you have a development environment and lots of time. It is not ideal and I do feel that if puppet is in the EPEL then the required ruby dependencies should be there but I only run one puppet server and a moderate number of clients so this is not a project I would take on. My contribution when I get a moment will be a how-to to prevent someone else going through my pain <SOLVED> On 19 October 2011 11:21, Alexandre <alexandre.fou...@gmail.com> wrote: > Why not use RVM ? It wll be easy to create a ruby env with its gems. > It is in /usr/local and completely independant from the system ruby > and all gems. I enforce not putting any files on the system which are > not part of a RPM. > > For example, i use the puppetmaster and puppet rpms, so that both run > and use the standard ruby 1.8.7 without any need of gem (i do not use > mysql). But for the cloud provisioner that needs a lot of gems which > do not exist as RPM, i put RVM and told it to have a ruby-1.8.7 with > my needed gems. I put the default on rvm to keep using the default > ruby, so that it will not impact on anything for my system, but i > created a RVM wrapper for the second ruby, so that that i use this > wrapper to run my puppet command when needing to do cloud actions. > > You could have a similar setup, but having your puppetmaster and > puppet client using the rvm wrapped ruby and gems (eg the mysql gem), > and you will not have to worry about trashing your system with files > not part of RPMs > > I have a Puppet recipe to install rvm, manage rubies, gems, etc... > Tell me if you are interested, i could post it > > > On 18 oct, 23:56, jcbollinger <john.bollin...@stjude.org> wrote: >> On Oct 18, 11:43 am, Michael Stahnke <stah...@puppetlabs.com> wrote: >> >> > On Tue, Oct 18, 2011 at 6:19 AM, jcbollinger <john.bollin...@stjude.org> >> > wrote: >> [...] >> > > I, on the other hand, would recommend avoiding gems altogether if >> > > you're using the system's Ruby (i.e. one you installed from an RPM, >> > > whether via yum or otherwise). Ruby modules installed via RPM are not >> > > (should not be) gems. Using both gem and rpm to manage the same Ruby >> > > installation is begging for trouble. >> >> > Why? The packages of many ruby libraries are basically gems wrapped >> > in RPM. Basically it allows the library/tool to be registered with >> > the RPM and gem database. I admit it's not my favorite thing to have >> > gems (and not RPMs), but technically there is almost nothing wrong >> > with it, other than future RPMs can't depend on something from a gem >> > install only. >> >> As others have described, if you use gems and RPMs on the same Ruby >> installation then you have two different sources of truth. They can >> and will disagree about what modules (to use a somewhat generic term) >> are installed. Their respective repositories can and will provide >> different versions of some modules, and different configurations of >> some other modules. Using both together on the same Ruby installation >> can and will make a hash of your Ruby library. Eventually. If you're >> lucky, you'll notice. >> >> Even RPMs registering their Ruby payloads with the gem database does >> not solve the problem, because gem is not so accommodating about >> synchronizing the RPM database. In any case, it is not safe to assume >> that *all* RPMs with Ruby payloads will install modules as gems. >> >> > There are plenty of other debates about rubygems, and whether or not >> > they are useful or helpful or anything. But as far as having a system >> > with ruby and using to gem to install things, it will work and is >> > always all that bad. >> >> Please don't misunderstand: I have no particular complaint about gem >> itself. If you want all its gemtacular goodness then install a local >> Ruby build and go wild in it with gems. As long as you put it in a >> reasonable place (e.g. /usr/local) no RPM will touch it, so no >> problem. >> >> Of course, you have no obligation whatever to do as I advise. If you >> choose to use both gems and RPMs on the same Ruby then I wish you luck >> -- you're a braver man than I. >> >> John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
