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... > > > > 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 > > 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. The general idea is good, see review of https://build.opensuse.org/request/show/213556 > > > > 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: [email protected] To contact the owner, e-mail: [email protected]
