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.
2. Ruby will be part of inst-sys (for YaST)
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.
3. The new package scheme should support maintenance better
A split between binaries, shared libraries, and Ruby stdlib seems
desirable
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 libruby2.1.so.2.0.0 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.
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.
6. ruby-devel, ruby-devel-extra, ruby-doc-ri
These would stay unchanged.
Comments ?
Thanks,
Klaus
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
