Hey Jeroen, thanks alot for your Ruby roundtable discussion at FUDCon. I was looking around for various solutions to the Ruby version compatibility problem for Fedora/Yum and recalled the 'alternatives' utility which I believe might help out w/ this problem as well.
It is shipped as part of the 'chkconfig' package so it's pretty standard on Fedora, and was (according to the manpage) originally written for this same problem w/ Perl.
http://linux.about.com/library/cmd/blcmdl8_alternatives.htm
I recall using it a while back to install various various of Java side by side in a single environment (pretty good overview here http://lanestechblog.blogspot.com/2008/03/using-alternatives-in-linux-to-use...).
I could see this being useful if we wanted to support installing many different versions of the Ruby interpreter or different Ruby interpreters entirely side by side on a single system.
One thing I'm not currently sure of is how we would handle the different ruby lib and gem paths depending on which alternative is setup. If we can swap in the correct lib / gem path depending on which alternative is selected (systemwide or by the user) we should be good.
Any thoughts on this? It might be a little more complicated than doing the different vendor/version site dirs alone but might provide a nice way for multiple version support.
-Mo
On 12/08/2009 02:38 AM, Mohammed Morsi wrote:
Hey Jeroen, thanks alot for your Ruby roundtable discussion at FUDCon. I was looking around for various solutions to the Ruby version compatibility problem for Fedora/Yum and recalled the 'alternatives' utility which I believe might help out w/ this problem as well.
Hi Mohammed,
please don't misunderstand me I was not ignoring you ;-) Sorry for my late response but I had been working on *exactly* what you describe here ;-)
-- Jeroen
On 12/24/2009 07:34 AM, Jeroen van Meeuwen wrote:
On 12/08/2009 02:38 AM, Mohammed Morsi wrote:
Hey Jeroen, thanks alot for your Ruby roundtable discussion at FUDCon. I was looking around for various solutions to the Ruby version compatibility problem for Fedora/Yum and recalled the 'alternatives' utility which I believe might help out w/ this problem as well.
Hi Mohammed,
please don't misunderstand me I was not ignoring you ;-) Sorry for my late response but I had been working on *exactly* what you describe here ;-)
I hate to be a naysayer without a better solution, but I have never felt that the alternatives was a great model. I tend to use environment variables and not alternatives. Would the java guys do it that way again if they could?
-- bk
On 12/24/2009 03:14 PM, Bryan Kearney wrote:
On 12/24/2009 07:34 AM, Jeroen van Meeuwen wrote:
On 12/08/2009 02:38 AM, Mohammed Morsi wrote:
Hey Jeroen, thanks alot for your Ruby roundtable discussion at FUDCon. I was looking around for various solutions to the Ruby version compatibility problem for Fedora/Yum and recalled the 'alternatives' utility which I believe might help out w/ this problem as well.
Hi Mohammed,
please don't misunderstand me I was not ignoring you ;-) Sorry for my late response but I had been working on *exactly* what you describe here ;-)
I hate to be a naysayer without a better solution, but I have never felt that the alternatives was a great model. I tend to use environment variables and not alternatives. Would the java guys do it that way again if they could?
I don't know of any alternatives - no pun intended.
If we were to do the work without alternatives, that's fine with me, but wouldn't it end up like... messy?
All shebangs would have to be #!/usr/bin/env ruby, right?
I think with environment variables rather then alternatives, given that ruby-1.9.1 would be the default stack, to execute facter with ruby-1.8.6 compares as follows:
ruby-1.8.6 /usr/bin/facter
env ruby=/usr/bin/ruby-1.8.6 /usr/bin/facter
but please you have more experience with the environment variables so correct me if I'm wrong.
-- Jeroen
On 12/25/2009 06:41 AM, Jeroen van Meeuwen wrote:
On 12/24/2009 03:14 PM, Bryan Kearney wrote:
On 12/24/2009 07:34 AM, Jeroen van Meeuwen wrote:
On 12/08/2009 02:38 AM, Mohammed Morsi wrote:
Hey Jeroen, thanks alot for your Ruby roundtable discussion at FUDCon. I was looking around for various solutions to the Ruby version compatibility problem for Fedora/Yum and recalled the 'alternatives' utility which I believe might help out w/ this problem as well.
Hi Mohammed,
please don't misunderstand me I was not ignoring you ;-) Sorry for my late response but I had been working on *exactly* what you describe here ;-)
I hate to be a naysayer without a better solution, but I have never felt that the alternatives was a great model. I tend to use environment variables and not alternatives. Would the java guys do it that way again if they could?
I don't know of any alternatives - no pun intended.
If we were to do the work without alternatives, that's fine with me, but wouldn't it end up like... messy?
All shebangs would have to be #!/usr/bin/env ruby, right?
I think with environment variables rather then alternatives, given that ruby-1.9.1 would be the default stack, to execute facter with ruby-1.8.6 compares as follows:
ruby-1.8.6 /usr/bin/facter
env ruby=/usr/bin/ruby-1.8.6 /usr/bin/facter
but please you have more experience with the environment variables so correct me if I'm wrong.
-- Jeroen _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Thinking about it, alternatives would give us a nice way to switch between Ruby interpreters on the fly, but thats about it, we would still need to have different versioned stacks due to the API incompatabilities, and the interpreter switching could be done through environment variables as you mentioned. Though it would be kinda cool to be able to switch between different versions of the official Ruby interpreter as well as JRuby, Maglev, or any other one w/ a simple targeted command, this was just a random idea I had to somewhat help tackle the API discreprancies, but agree its more work/complexity than its worth at this moment.
-Mo
Hi there ruby fedorians
¿On the packaging front of ruby/rails apps, where are we standing?
afaik gems are being packaged but im not 100% happy with the results, documentation is one those missing parts (even if the original rdocs are bad), by example just yesterday:
yum install ruby-ncurses
i missed right away my gem server with ruby-ncurses rdoc documentation so i removed the rpm and the installed using gem command.
I would like to start on packaging main ruby/rails apps like redmine but before that i would like to know more experienced people to advice me (YOU ;) )
in parallel i would suggest we use a redmine to track our issues, sounds good? well we already have one in latam region for latam rpmdev group, if everybody agree we could use it.
http://rpmdev.proyectofedora.org/projects (ruby sig project can be created, im the manager of the site)
kregards
Guillermo
ruby-sig@lists.fedoraproject.org
-
"Guillermo Gómez S." -
Bryan Kearney -
Jeroen van Meeuwen -
Mo Morsi