Mailinglist Archive: opensuse-ruby (69 mails)

< Previous Next >
Re: [opensuse-ruby] A new packaging scheme for Ruby 2.1
On Wed, 22 Jan 2014 15:27:26 +0100
Sascha Peilicke <speilicke@xxxxxxxx> wrote:

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:
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?

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.


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

From current experience from SLMS and WebYaST we really update gems
only for security fixes or for new version of product.


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 is same as now, YaST move forward together with whole SLE unless
decided otherwise.

So it will behave same like now. If you create product based on SLE,
then you should use what SLE version provide or if you want own
version, then
1) convince other and release update together with all testing

2) bundle your specific version like studio do it now, but then you are
on your side with security problems, bugs and other stuff that we
should share


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.

Yes, that is what I expect as I write above. I don't see your point why
you want multiple ruby versions and multiple gems versions.


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 modules.

"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.

Yes and it happen between major releases and we fix it. I think we
should be more clear about support of ruby.

Josef
--
To unsubscribe, e-mail: opensuse-ruby+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-ruby+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation
Follow Ups