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