On Wednesday 22 January 2014 15:44:54 Josef Reidinger wrote:
On Wed, 22 Jan 2014 15:27:26 +0100
Sascha Peilicke <speilicke@suse.com> wrote:
On Wednesday 22 January 2014 14:49:41 Josef Reidinger wrote:
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).
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: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org