On Wed, 22 Jan 2014 14:41:06 +0100 Sascha Peilicke <speilicke@suse.com> wrote:
On Wednesday 22 January 2014 14:21:30 Stephan Kulow wrote:
On 22.01.2014 14:19, Sascha Peilicke wrote:
On Wednesday 22 January 2014 13:52:30 Jordi Massaguer Pla wrote:
On 01/22/2014 01:23 PM, Klaus Kaempf wrote:
Hi,
going forward, Ruby becomes more important in the openSUSE and SLES codebase. This is why Coolo asked me to come up with a new Ruby packaging scheme. Read on to learn about my current thinking in this regard.
What are the goals ?
1. revert the ruby, rubyXY, and ruby-common split
Initially done to allow multiple Ruby versions in parallel, it wasn't really used and developers use rvm or rbenv to achieve the same effect. From a buildservice perspective, this split cause more headaches than it provided value.
in studio product we have ruby 1.8 and ruby 1.9 at the same time because the first one is a requirement from WebYast and the second one from studio itself. I am not saying this is good or desirable, but please take in mind this kind of situation.
Mucho agreed. I strongly vote for keeping parallel-installability. For several products (like Cloud) this is a must-have. And it's already present in openSUSE (and thus SLE12).
2. Ruby will be part of inst-sys (for YaST)
Another good reason why you want parallel installs. ATM ruby-2.1 is fresh like cheese. But this version on SLE_X. Let 6 years pass and take one of our Ruby- based products. It will likely use ruby-42 by then. You can't drop ruby21 because of yast but you need ruby42 because of $PRODUCT...
For this to work you also need to make the gems parallel installable - do you want to work on that?
No :-) I have enough on the plate with Python. Also, it's semi-working for at least rake/rails.
But it's a good point. You have to keep all the gems Yast depends on with a fixed revision for the next 13 years (SLE).
No, it doesn't make any sense. Yast can and probably will move forward. Of course if you use 13 years old DVD, then you cannot expect that you get newer ruby, but it is just inst-sys. Installed system can contain the newest yast with the newest ruby. That is also reason why we make installer independent on installed system, so installator no longer call yast modules on installer system.
Therefore I would recommend building a minimal ruby package that is isolated (not on any PATH) and only used by yast. The package would only include libruby$SOVER, a "rubyyast" binary, some stdlib (whatever you need) and all yast's gem dependencies in matching versions. Of course those have to be installed in a private gem path.
I really do not like it and I think it is not needed. Also I hope we upgrade more aggressive in Service Packs. So no speciallity for yast.
This way you can independently update yast without risking to break your customer's (or other SUSE) applications. IMO that's the only sane option you have.
That is more important point, do SUSE want to keep support and guarantie for customers that their ruby 2.1 application will work for next 13 years? If so, then it is way to heaven, as we need to provide for it support, security fixes and other stuff, that is not so easy. YaST can move forward quite quickly and in fact only step between 1.8 and 1.9 break some stuff and mostly in its C bindings and not in all modules. Josef -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org