Mailinglist Archive: opensuse-ruby (69 mails)

< Previous Next >
Re: [opensuse-ruby] A new packaging scheme for Ruby 2.1
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...

As you know, size matters.
Looking at the ruby20 package, it has an install size of 18MB
However, 'du -sh /usr/share/doc/packages/ruby20' reports 5.9 MB
just for documentation.

Yes, that better belongs into a doc package.

3. The new package scheme should support maintenance better

A split between binaries, shared libraries, and Ruby stdlib seems

Packaging proposal:

I'd like to generate the following packages for Ruby 2.1

1. ruby-2.1

This would provide binaries (ruby, irb, rake, gem, ...) and a minimal
set of documentation (changelog, readme, news, ...)

2. libruby2

This would only provide the shared library

3. ruby-stdlib

This would provide the /usr/lib64/ruby/2.1.0/ directory tree.

4. ruby-doc

This would provide the full Ruby documentation including samples.

The general idea is good, see review of

5. ruby-macros ?

This would be a new name for ruby-common, a package only used for
building ruby GEM packages.
Actually, I'm not happy about the name. It should reflect the package
usage. ruby-devel-build or ruby-build-macros could be alternatives.

Dunno if it's worth discussing package names but it's established practice to
name RPM macro packages for software foo $FOO as $FOO-macros or $FOO-rpm-
macros. Maybe the later is more obvious.

6. ruby-devel, ruby-devel-extra, ruby-doc-ri

These would stay unchanged.

Also touched by the review above.

Comments ?

With multiple Ruby versions in mind, the list would rather look like ruby21,
libruby2_1, ruby21-doc, ruby21-rpm-macros. Just like we have it ATM.
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