[opensuse-ruby] A new packaging scheme for Ruby 2.1
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. 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 -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
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: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Jordi Massaguer Pla <jmassaguerpla@suse.de> [Jan 22. 2014 13:52]:
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.
The new packaging scheme will be applied from Ruby-2.1 on forward. It should not affect previous distributions. Otoh, having a single Ruby version will prevent such crazy setups as above in the future ;-) Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
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: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
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:
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...
For this to work you also need to make the gems parallel installable - do you want to work on that? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
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:
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...
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 have. -- 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@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Wed, 22 Jan 2014 14:41:06 +0100 Sascha Peilicke <speilicke@suse.com> 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:
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...
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).
No, it doesn't make any sense. Yast can and probably will move forward. Of course if you use 13 years old DVD, then you cannot expect that you get newer ruby, but it is just inst-sys. Installed system can contain the newest yast with the newest ruby. That is also reason why we make installer independent on installed system, so installator no longer call yast modules on installer system.
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.
I really do not like it and I think it is not needed. Also I hope we upgrade more aggressive in Service Packs. So no speciallity for yast.
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 have.
That is more important point, do SUSE want to keep support and guarantie for customers that their ruby 2.1 application will work for next 13 years? If so, then it is way to heaven, as we need to provide for it support, security fixes and other stuff, that is not so easy. YaST can move forward quite quickly and in fact only step between 1.8 and 1.9 break some stuff and mostly in its C bindings and not in all modules. Josef -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Wednesday 22 January 2014 14:49:41 Josef Reidinger wrote:
On Wed, 22 Jan 2014 14:41:06 +0100
Sascha Peilicke <speilicke@suse.com> 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:
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...
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).
No, it doesn't make any sense. Yast can and probably will move forward. Of course if you use 13 years old DVD, then you cannot expect that you get newer ruby, but it is just inst-sys. Installed system can contain the newest yast with the newest ruby. That is also reason why we make installer independent on installed system, so installator no longer call yast modules on installer system.
I don't care about the inst-sys, I am talking about the running system and the fancy plans I read here. I'll reply to the last paragraph.
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.
I really do not like it and I think it is not needed. Also I hope we upgrade more aggressive in Service Packs. So no speciallity for yast.
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 have.
That is more important point, do SUSE want to keep support and guarantie for customers that their ruby 2.1 application will work for next 13 years?
For customers that all depends on the support statement for Ruby and whether they are advised (or even want to) use the distro packages at all. The situation is slightly trickier for other SUSE products. Previously nobody cared about Ruby issues and every Ruby-based products has overlay packages (or custom solutions). Since we don't expect customers to run Studio and Cloud on the same (virtual) box, this is ok. But now we're introducing Ruby to the base system. It will be an integral part that we will want to keep as stable as possible in order to not break it. Since we all know that rubygems can (and often do) break API/ABI compatibility even at patch-level releases, I bet people want to stay with their versions as long as possible. Let's do it by example. Say yast on SLE_12 wants to update rubygem-foo-1.2.0 to 1.2.1 and prepares a patch. Since we don't know if that will break it for Cloud, we'll have to test it. So cloud guys (or hopefully QA) will take it and deploy cloud with this. Due to the dynamic nature of Ruby, they may or may not uncover a regression. Therefore, cloud developers have to check the git diff between 1.2.0 and 1.2.1 to confirm or adjust their code. In the latter case, they have to create a maintenance update too. So cloud customers are then advised to install both at the same time. Doesn't sound too realistic? We had these issues before with OBS back when API and WebUI where separate codebases. If you now say "Yast probably will move forward", I would expect some more gem updates in the future. That would be a real testing challenge. It will interfere with interlocks, product RCs and freezes and all kinds of things you can't imagine. It's the same reason why we don't update glibc on SLE. So ruby21 would be around at least until SLE_12_SP1. So it may be very likely we switch ruby and gem versions only between service packs. That would leave more room for products to adjust.
If so, then it is way to heaven, as we need to provide for it support, security fixes and other stuff, that is not so easy.
It's at least a solution worth considering.
YaST can move forward quite quickly and in fact only step between 1.8 and 1.9 break some stuff and mostly in its C bindings and not in all modules.
"break some stuff" and "not in all modules" is exactly what I mean :-) Between 1.8 and 1.9 I only say block-local scope. -- 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@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Sascha Peilicke <speilicke@suse.com> [Jan 22. 2014 15:27]:
It's the same reason why we don't update glibc on SLE. So ruby21 would be around at least until SLE_12_SP1. So it may be very likely we switch ruby and gem versions only between service packs. That would leave more room for products to adjust.
Well, that would be my expectation. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Wed, 22 Jan 2014 15:27:26 +0100 Sascha Peilicke <speilicke@suse.com> wrote:
On Wednesday 22 January 2014 14:49:41 Josef Reidinger wrote:
On Wed, 22 Jan 2014 14:41:06 +0100
Sascha Peilicke <speilicke@suse.com> 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: > 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...
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).
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 have.
That is more important point, do SUSE want to keep support and guarantie for customers that their ruby 2.1 application will work for next 13 years?
For customers that all depends on the support statement for Ruby and whether they are advised (or even want to) use the distro packages at all. The situation is slightly trickier for other SUSE products. Previously nobody cared about Ruby issues and every Ruby-based products has overlay packages (or custom solutions). Since we don't expect customers to run Studio and Cloud on the same (virtual) box, this is ok.
But now we're introducing Ruby to the base system. It will be an integral part that we will want to keep as stable as possible in order to not break it. Since we all know that rubygems can (and often do) break API/ABI compatibility even at patch-level releases, I bet people want to stay with their versions as long as possible. Let's do it by example.
If they want to stay on given version without security updates, then they should use bundler. If you want security fixes then you need to use supported version. Do you expect we will fix all security fixes for gems that are 13 years old and noone support it beside us? And to correct you, yast is no longer part of base system. You can install system without yast. And I hope we start looking at yast as product, that configure system and not as oppurtinity to use all rubygems that yast use in our production system with long support.
Say yast on SLE_12 wants to update rubygem-foo-1.2.0 to 1.2.1 and prepares a patch. Since we don't know if that will break it for Cloud, we'll have to test it. So cloud guys (or hopefully QA) will take it and deploy cloud with this. Due to the dynamic nature of Ruby, they may or may not uncover a regression. Therefore, cloud developers have to check the git diff between 1.2.0 and 1.2.1 to confirm or adjust their code. In the latter case, they have to create a maintenance update too. So cloud customers are then advised to install both at the same time.
Thats what we do now. And it is exactly same you need to do if you update glibc, glib or any other library. So question is when yast will update such gem? 1) when there is security fix -> all must update 2) when there is new feature that new yast feature need it -> will be in new Service Pack, so cloud need to be adapted when it is based on next release of SLE From current experience from SLMS and WebYaST we really update gems only for security fixes or for new version of product.
Doesn't sound too realistic? We had these issues before with OBS back when API and WebUI where separate codebases. If you now say "Yast probably will move forward", I would expect some more gem updates in the future. That would be a real testing challenge. It will interfere with interlocks, product RCs and freezes and all kinds of things you can't imagine.
It is same as now, YaST move forward together with whole SLE unless decided otherwise. So it will behave same like now. If you create product based on SLE, then you should use what SLE version provide or if you want own version, then 1) convince other and release update together with all testing 2) bundle your specific version like studio do it now, but then you are on your side with security problems, bugs and other stuff that we should share
It's the same reason why we don't update glibc on SLE. So ruby21 would be around at least until SLE_12_SP1. So it may be very likely we switch ruby and gem versions only between service packs. That would leave more room for products to adjust.
Yes, that is what I expect as I write above. I don't see your point why you want multiple ruby versions and multiple gems versions.
If so, then it is way to heaven, as we need to provide for it support, security fixes and other stuff, that is not so easy.
It's at least a solution worth considering.
YaST can move forward quite quickly and in fact only step between 1.8 and 1.9 break some stuff and mostly in its C bindings and not in all modules.
"break some stuff" and "not in all modules" is exactly what I mean :-) Between 1.8 and 1.9 I only say block-local scope.
Yes and it happen between major releases and we fix it. I think we should be more clear about support of ruby. Josef -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Wednesday 22 January 2014 15:44:54 Josef Reidinger wrote:
On Wed, 22 Jan 2014 15:27:26 +0100
Sascha Peilicke <speilicke@suse.com> wrote:
On Wednesday 22 January 2014 14:49:41 Josef Reidinger wrote:
On Wed, 22 Jan 2014 14:41:06 +0100
Sascha Peilicke <speilicke@suse.com> 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: >> 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...
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).
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 have.
That is more important point, do SUSE want to keep support and guarantie for customers that their ruby 2.1 application will work for next 13 years?
For customers that all depends on the support statement for Ruby and whether they are advised (or even want to) use the distro packages at all. The situation is slightly trickier for other SUSE products. Previously nobody cared about Ruby issues and every Ruby-based products has overlay packages (or custom solutions). Since we don't expect customers to run Studio and Cloud on the same (virtual) box, this is ok.
But now we're introducing Ruby to the base system. It will be an integral part that we will want to keep as stable as possible in order to not break it. Since we all know that rubygems can (and often do) break API/ABI compatibility even at patch-level releases, I bet people want to stay with their versions as long as possible. Let's do it by example.
If they want to stay on given version without security updates, then they should use bundler. If you want security fixes then you need to use supported version. Do you expect we will fix all security fixes for gems that are 13 years old and noone support it beside us?
This is probably getting off-topic but that was exactly my initial fear when the Ruby port was announced. We will have to fix gems on SLE_12_GA as long as it is supported.
And to correct you, yast is no longer part of base system. You can install system without yast. And I hope we start looking at yast as product, that configure system and not as oppurtinity to use all rubygems that yast use in our production system with long support.
Ok, but still I don't know if we can ask customers "please drop yast before you install cloud".
Say yast on SLE_12 wants to update rubygem-foo-1.2.0 to 1.2.1 and prepares a patch. Since we don't know if that will break it for Cloud, we'll have to test it. So cloud guys (or hopefully QA) will take it and deploy cloud with this. Due to the dynamic nature of Ruby, they may or may not uncover a regression. Therefore, cloud developers have to check the git diff between 1.2.0 and 1.2.1 to confirm or adjust their code. In the latter case, they have to create a maintenance update too. So cloud customers are then advised to install both at the same time.
Thats what we do now. And it is exactly same you need to do if you update glibc, glib or any other library. So question is when yast will update such gem?
1) when there is security fix -> all must update
Agreed.
2) when there is new feature that new yast feature need it -> will be in new Service Pack, so cloud need to be adapted when it is based on next release of SLE
Agreed. But this wasn't entirely clear from the discussion so far.
From current experience from SLMS and WebYaST we really update gems only for security fixes or for new version of product.
That sort of contradicts statements in other parts of this thread.
Doesn't sound too realistic? We had these issues before with OBS back when API and WebUI where separate codebases. If you now say "Yast probably will move forward", I would expect some more gem updates in the future. That would be a real testing challenge. It will interfere with interlocks, product RCs and freezes and all kinds of things you can't imagine. [...] -- 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@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Sascha Peilicke <speilicke@suse.com> [Jan 22. 2014 14:41]:
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.
We are already talking about this with the SLE release managers. For reasons outside of YaST.
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 have.
My assumption is that we will not maintain a single Ruby version for long but rather follow upstream. Otherwise its a maintenance nightmare. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Wednesday 22 January 2014 15:15:51 Klaus Kaempf wrote:
* Sascha Peilicke <speilicke@suse.com> [Jan 22. 2014 14:41]:
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.
We are already talking about this with the SLE release managers. For reasons outside of YaST.
Nice.
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 have.
My assumption is that we will not maintain a single Ruby version for long but rather follow upstream. Otherwise its a maintenance nightmare.
In the context of yast + isolated or SLE_12 in general? -- 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@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Sascha Peilicke <speilicke@suse.com> [Jan 22. 2014 15:28]:
On Wednesday 22 January 2014 15:15:51 Klaus Kaempf wrote:
My assumption is that we will not maintain a single Ruby version for long but rather follow upstream. Otherwise its a maintenance nightmare.
In the context of yast + isolated or SLE_12 in general?
SLE 12 in general. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
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:
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
On 01/22/2014 01:23 PM, Klaus Kaempf wrote: 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
On Wednesday 22 January 2014 13:52:30 Jordi Massaguer Pla wrote: 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 have.
+1 -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Sascha Peilicke <speilicke@suse.com> [Jan 22. 2014 14:19]:
Mucho agreed. I strongly vote for keeping parallel-installability. For several products (like Cloud) this is a must-have.
Hmm, I somewhat struggle with that. Why's it a 'must-have' ?
And it's already present in openSUSE (and thus SLE12).
Well, this proposal is about removing this parallel-installability for 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...
I'm pretty sure we will be able to adapt yast to ruby-4.2. So this argument does not hold for me.
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.
Yes, ruby-rpm-macros seems like a good name. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Wednesday 22 January 2014 15:13:02 Klaus Kaempf wrote:
* Sascha Peilicke <speilicke@suse.com> [Jan 22. 2014 14:19]:
Mucho agreed. I strongly vote for keeping parallel-installability. For several products (like Cloud) this is a must-have.
Hmm, I somewhat struggle with that. Why's it a 'must-have' ?
So Cloud-3 currently is still based on 1.8 and rails-2.3. We very recently got more manpower and I expect this to change soon. But at least ATM, we're not 2.1 ready.
And it's already present in openSUSE (and thus SLE12).
Well, this proposal is about removing this parallel-installability for 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...
I'm pretty sure we will be able to adapt yast to ruby-4.2. So this argument does not hold for me.
That is not my point, the question is if $SUSE_PRODUCT_X will be similarly capable to adapt. Let's do it the other way around, yast moved to ruby-4.2 but cloud-9 wants ruby-2.1. Of course you could ask "dear cloud guys", please fix this. But this would probably only happen for cloud-10. And our SLE_12 using customer may or may not want to upgrade to it.
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.
Yes, ruby-rpm-macros seems like a good name.
Klaus
-- 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@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Sascha Peilicke <speilicke@suse.com> [Jan 22. 2014 15:35]:
On Wednesday 22 January 2014 15:13:02 Klaus Kaempf wrote:
* Sascha Peilicke <speilicke@suse.com> [Jan 22. 2014 14:19]:
Mucho agreed. I strongly vote for keeping parallel-installability. For several products (like Cloud) this is a must-have.
Hmm, I somewhat struggle with that. Why's it a 'must-have' ?
So Cloud-3 currently is still based on 1.8 and rails-2.3. We very recently got more manpower and I expect this to change soon. But at least ATM, we're not 2.1 ready.
Then Cloud-6 on SLE12 would have to provide and maintain its own ruby18 package, installed to /opt/ruby18.
That is not my point, the question is if $SUSE_PRODUCT_X will be similarly capable to adapt.
$SUSE_PRODUCT_X, based on SLES_Y_ServicePack_Z, would either use the official SLES_Y_ServicePack_Z Ruby version or provide and maintain its own version. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Wed, Jan 22, 2014 at 01:23:25PM +0100, Klaus Kaempf wrote:
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.
Which use case needs 1+2+3 separated?
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. -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner
Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
* Martin Vidner <mvidner@suse.cz> [Jan 22. 2014 14:58]:
On Wed, Jan 22, 2014 at 01:23:25PM +0100, Klaus Kaempf wrote:
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.
Which use case needs 1+2+3 separated?
Just for smaller maintenance updates. Plus a separate ruby-stdlib might help with a future ruby-stdlib-as-gems approach. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Wed, Jan 22, 2014 at 03:18:13PM +0100, Klaus Kaempf wrote:
* Martin Vidner <mvidner@suse.cz> [Jan 22. 2014 14:58]:
Which use case needs 1+2+3 separated?
Just for smaller maintenance updates.
Plus a separate ruby-stdlib might help with a future ruby-stdlib-as-gems approach.
YAGNI ;-) And smaller maintenance updates are a solved problem with deltarpms, aren't they? -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
* Martin Vidner <mvidner@suse.cz> [Jan 22. 2014 15:25]:
On Wed, Jan 22, 2014 at 03:18:13PM +0100, Klaus Kaempf wrote:
* Martin Vidner <mvidner@suse.cz> [Jan 22. 2014 14:58]:
Which use case needs 1+2+3 separated?
Just for smaller maintenance updates.
Plus a separate ruby-stdlib might help with a future ruby-stdlib-as-gems approach.
YAGNI ;-) And smaller maintenance updates are a solved problem with deltarpms, aren't they?
Not really. deltarpms are for people with slow connections, they still need considerable time and memory resources for installation. To cite /etc/zypp/zypp.conf: ## Using a delta rpm will decrease the download size for package updates ## since it does not contain all files of the package but only the binary ## diff of changed ones. Recreating the rpm package on the local machine ## is an expensive operation (memory,CPU). If your network connection is ## not too slow, you benefit from disabling .delta.rpm. In enterprise, people are not concerned about download sizes, but about time-to-install. Smaller packages are faster to install. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Wed, 22 Jan 2014 15:18:13 +0100 Klaus Kaempf <kkaempf@suse.de> wrote:
* Martin Vidner <mvidner@suse.cz> [Jan 22. 2014 14:58]:
On Wed, Jan 22, 2014 at 01:23:25PM +0100, Klaus Kaempf wrote:
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.
Which use case needs 1+2+3 separated?
Just for smaller maintenance updates.
I think it is not enough value to do it. It is more confusing to users. I think that if you want rid of multiversion there should be one "ruby" package that contains the latest upstream stable version.
Plus a separate ruby-stdlib might help with a future ruby-stdlib-as-gems approach.
Really? How? If upstread decide to move e.g. OpenURI to own gem how this can help? all projects using OpenURI must be adapted or doesn't work with next ruby version and next ruby or ruby-stdlib do not contain it. Josef P.S. Thanks to write suggestion on mailing list before you start implementing ;)
Klaus
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Wednesday 22 January 2014 15:28:46 Josef Reidinger wrote:
[...]
P.S. Thanks to write suggestion on mailing list before you start implementing ;)
+100, this is much appreciated. -- 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@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Josef Reidinger <jreidinger@suse.cz> [Jan 22. 2014 15:28]:
On Wed, 22 Jan 2014 15:18:13 +0100 Klaus Kaempf <kkaempf@suse.de> wrote:
* Martin Vidner <mvidner@suse.cz> [Jan 22. 2014 14:58]:
On Wed, Jan 22, 2014 at 01:23:25PM +0100, Klaus Kaempf wrote:
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.
Which use case needs 1+2+3 separated?
Just for smaller maintenance updates.
I think it is not enough value to do it.
Doing it is simple, just more %package and %file tags.
It is more confusing to users. I think that if you want rid of multiversion there should be one "ruby" package that contains the latest upstream stable version.
Users won't notice since its handled by dependencies.
P.S. Thanks to write suggestion on mailing list before you start implementing ;)
Well, I did start implementing the new scheme in home:kwk:ruby to get some idea about its complexity. It turned out to be pretty simple. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Dne 22.1.2014 15:41, Klaus Kaempf napsal(a):
* Josef Reidinger <jreidinger@suse.cz> [Jan 22. 2014 15:28]:
On Wed, 22 Jan 2014 15:18:13 +0100 Klaus Kaempf <kkaempf@suse.de> wrote:
* Martin Vidner <mvidner@suse.cz> [Jan 22. 2014 14:58]:
On Wed, Jan 22, 2014 at 01:23:25PM +0100, Klaus Kaempf wrote:
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.
Which use case needs 1+2+3 separated?
Just for smaller maintenance updates.
I think it is not enough value to do it.
Doing it is simple, just more %package and %file tags.
The real cost is in using it. More complicated package tree = more confusion about: * what exactly needs to be installed for some purpose and what is optional (complicates e.g. writing READMEs and various manuals) * what files belong to which package * what depends (or should depend) on what * etc. (I am saying that as a person who had to deal with understanding several such package trees in the last few weeks and who just yesterday wrote a workaround for a bug resulting from sloppy package splitting.) -- David Majda SUSE developer -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* David Majda <dmajda@suse.cz> [Jan 22. 2014 17:09]:
The real cost is in using it. More complicated package tree = more confusion about:
Agreed. And that's actually the motivation to revert the current split of ruby,rubyXY,ruby-common,... In the new proposal, you just install 'ruby' and all sub-packages will come in via dependencies (just like any other shared libraries).
* what exactly needs to be installed for some purpose and what is optional (complicates e.g. writing READMEs and various manuals)
'ruby' is all that's needed.
* what files belong to which package
The new scheme will be documented on the opensuse wiki.
* what depends (or should depend) on what
ruby requires libruby2_1, ruby-stdlib, and recommends ruby-doc. Hth, Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 22/01/14 13:23, 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.
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.
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? 5. What prevent those to go to ruby-devel? -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Duncan Mac-Vicar P. <dmacvicar@suse.de> [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.
5. What prevent those to go to ruby-devel?
Nothing. A merge of ruby-common to ruby-devel is easily doable. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Duncan Mac-Vicar P. <dmacvicar@suse.de> [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.
On 28.01.2014 16:29, Klaus Kaempf wrote: 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: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Stephan Kulow <coolo@suse.de> [Jan 28. 2014 16:34]:
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.
Thanks Stefan. This should make the packaging proposal final. As I haven't seen anyone wanting to maintain the old packaging layout going forward, I will no go ahead and submit ruby-2.1 according to the new proposal. Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Stephan Kulow <coolo@suse.de> [Jan 28. 2014 16:34]:
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.
Looking a bit closer, I'd suggest to merge ruby-common with the main ruby package. ruby-common (resp. ruby-rpm-macros) is a 14kb (_kilo_bytes) package and not really worth to keep separately. Comments ? Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 30.01.2014 12:59, Klaus Kaempf wrote:
* Stephan Kulow <coolo@suse.de> [Jan 28. 2014 16:34]:
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.
Looking a bit closer, I'd suggest to merge ruby-common with the main ruby package.
ruby-common (resp. ruby-rpm-macros) is a 14kb (_kilo_bytes) package and not really worth to keep separately.
Comments ?
Fine with me - that's how it's done in the perl package. The only thing to remember: you need to keep the macros around in the backport project. The gems buildrequire ruby-macros >= 3 - which package provides that shouldn't matter. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
participants (8)
-
David Majda -
Duncan Mac-Vicar P. -
Jordi Massaguer Pla -
Josef Reidinger -
Klaus Kaempf -
Martin Vidner -
Sascha Peilicke -
Stephan Kulow