On 28.01.2014 16:29, Klaus Kaempf wrote: > * Duncan Mac-Vicar P. <[email protected]> [Jan 28. 2014 14:53]: >>> >>> 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. >> >> I agree with .4. >> >> 2. is useful only for extensions I guess. >> 3. Not sure if this bring value. Can ruby be already be ran without the >> stdlib or will the package have to require it anyway? > > 2+3 would be a hard dependency of the main ruby package. The split is > just for maintenance/upgrade reasons, to make fixes easier to > distribute and faster to install. libruby* is actually required by shared library packaging policy.
> >> 5. What prevent those to go to ruby-devel? > > Nothing. A merge of ruby-common to ruby-devel is easily doable. > The only benefit of keeping the split is that you can avoid ruby-devel while building 99% of the gems. Greetings, Stephan -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
