Mailinglist Archive: opensuse-ruby (69 mails)

< Previous Next >
Re: [opensuse-ruby] A new packaging scheme for Ruby 2.1
On Wednesday 22 January 2014 14:49:41 Josef Reidinger wrote:
On Wed, 22 Jan 2014 14:41:06 +0100

Sascha Peilicke <speilicke@xxxxxxxx> 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:

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

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.

I don't care about the inst-sys, I am talking about the running system and the
fancy plans I read here. I'll reply to the last paragraph.

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?

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.

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.

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.

It's the same reason why we don't update glibc on SLE. So ruby21 would be
around at least until SLE_12_SP1. So it may be very likely we switch ruby and
gem versions only between service packs. That would leave more room for
products to adjust.

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.

It's at least a solution worth considering.

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

"break some stuff" and "not in all modules" is exactly what I mean :-) Between
1.8 and 1.9 I only say block-local scope.
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-ruby+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation