Hi trey, I put it here: https://github.com/alexfouche/rvm
On 19 oct, 21:07, Robert Mortimer <robert.morti...@gmail.com> wrote: > 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 > > athttp://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.
