On Wednesday 22 January 2014 15:44:54 Josef Reidinger wrote: > On Wed, 22 Jan 2014 15:27:26 +0100 > > Sascha Peilicke <[email protected]> wrote: > > On Wednesday 22 January 2014 14:49:41 Josef Reidinger wrote: > > > On Wed, 22 Jan 2014 14:41:06 +0100 > > > > > > Sascha Peilicke <[email protected]> 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). > > > > > > > > > > > > > > > > > > > > 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? > > > > For customers that all depends on the support statement for Ruby and > > whether they are advised (or even want to) use the distro packages at > > all. The situation is slightly trickier for other SUSE products. > > Previously nobody cared about Ruby issues and every Ruby-based > > products has overlay packages (or custom solutions). Since we don't > > expect customers to run Studio and Cloud on the same (virtual) box, > > this is ok. > > > > But now we're introducing Ruby to the base system. It will be an > > integral part that we will want to keep as stable as possible in > > order to not break it. Since we all know that rubygems can (and often > > do) break API/ABI compatibility even at patch-level releases, I bet > > people want to stay with their versions as long as possible. Let's do > > it by example. > > If they want to stay on given version without security updates, then > they should use bundler. If you want security fixes then you need to > use supported version. Do you expect we will fix all security fixes for > gems that are 13 years old and noone support it beside us?
This is probably getting off-topic but that was exactly my initial fear when the Ruby port was announced. We will have to fix gems on SLE_12_GA as long as it is supported. > And to correct you, yast is no longer part of base system. You can > install system without yast. And I hope we start looking at yast as > product, that configure system and not as oppurtinity to use all > rubygems that yast use in our production system with long support. Ok, but still I don't know if we can ask customers "please drop yast before you install cloud". > > Say yast on SLE_12 wants to update rubygem-foo-1.2.0 to 1.2.1 and > > prepares a patch. Since we don't know if that will break it for > > Cloud, we'll have to test it. So cloud guys (or hopefully QA) will > > take it and deploy cloud with this. Due to the dynamic nature of > > Ruby, they may or may not uncover a regression. Therefore, cloud > > developers have to check the git diff between 1.2.0 and 1.2.1 to > > confirm or adjust their code. In the latter case, they have to create > > a maintenance update too. So cloud customers are then advised to > > install both at the same time. > > Thats what we do now. And it is exactly same you need to do if you > update glibc, glib or any other library. So question is when yast will > update such gem? > > 1) when there is security fix -> all must update Agreed. > 2) when there is new feature that new yast feature need it -> will be > in new Service Pack, so cloud need to be adapted when it is based on > next release of SLE Agreed. But this wasn't entirely clear from the discussion so far. > From current experience from SLMS and WebYaST we really update gems > only for security fixes or for new version of product. That sort of contradicts statements in other parts of this thread. > > Doesn't sound too realistic? We had these issues before with OBS back > > when API and WebUI where separate codebases. If you now say "Yast > > probably will move forward", I would expect some more gem updates in > > the future. That would be a real testing challenge. It will interfere > > with interlocks, product RCs and freezes and all kinds of things you > > can't imagine. [...] -- 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]
