Mailinglist Archive: opensuse-ruby (69 mails)

< Previous Next >
Re: [opensuse-ruby] A new packaging scheme for Ruby 2.1
On Wednesday 22 January 2014 15:44:54 Josef Reidinger wrote:
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?

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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-ruby+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation