Mailinglist Archive: opensuse-ruby (69 mails)

< Previous Next >
Re: [opensuse-ruby] A new packaging scheme for Ruby 2.1
  • From: Jordi Massaguer Pla <jmassaguerpla@xxxxxxx>
  • Date: Wed, 22 Jan 2014 15:53:55 +0100
  • Message-id: <>

On 01/22/2014 02:41 PM, Sascha Peilicke 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

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

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.

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


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

< Previous Next >
List Navigation