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). 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. 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. -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
