[opensuse-ruby] Revised gem packaging
Hi, Want to know what I did for #hackweek8? I pulled ruby packaging apart and put it back together. I... - split ruby-common from the ruby package, so it can also be used from ruby 1.8 distros - added patched rpms to devel:languages:ruby:backports for older distros to support overwriting macros and ruby dependencies (11.4 and sle11) - enhanced the %gem_install macro - wrote a gemspec to rpm converter to have requires and provides in rpm automatic without gem2rpm run - changed the gem2rpm template heavily The key idea behind my work was that creating gem.rpm with gem2rpm is easy, updating is problematic (and over half the gems in dlre being outdated kind of proves my point :) So the new template has no requires and no provides, because rpm can find out both from the installed .gemspec. E.g. I found a couple of cases that left broken provides with an update (e.g. 0.8.X providing _0_7). But this strange suffixing is no longer necessary anyway. E.g. rails-3_2 has these automatic requires now: ruby(abi) = 1.9.1 rubygem(1.9.1:actionmailer) = 3.2.7 rubygem(1.9.1:actionpack) = 3.2.7 rubygem(1.9.1:activerecord) = 3.2.7 rubygem(1.9.1:activeresource) = 3.2.7 rubygem(1.9.1:activesupport) = 3.2.7 rubygem(1.9.1:bundler) >= 1.0 rubygem(1.9.1:bundler) < 2 rubygem(1.9.1:railties) = 3.2.7 No more bundler-1_0, but a simple bundler < 2. The automatic provides cover the old names, but I kind of hope we can drop them in the future: rubygem(1.9.1:rails) = 3.2.7 rubygem(rails) = 3.2.7 rubygem-rails = 3.2.7 rubygem-rails-3 = 3.2.7 rubygem-rails-3_2 = 3.2.7 rubygem-rails-3_2_7 = 3.2.7 I do not generate buildrequires in the template either, even though this is a rather tough call. We need buildrequires mainly to check that the dependencies are in the repo, but they create several problems: - gems build in "rings" and require a finished -> succeeded step for every ring, a rails update are 4 such rings. YOU GET CRAZY if the obs is busy! - you can't rely on automatism as the gem specificies "rails > 1.0", but there are 4 such rails versions and the build service wants to know which one you mean. And in case the rails version requires a rack > 1.1, it wants to know which one of those. YOU GET CRAZY! As gem packaging has to be 99% automatic to compete with out of rpm gem, I went for calling gem install with -f and ignore buildignores. To have a way to check dependencies in OBS, I created a small package called "all-good", that itself buildrequires all gems in the repository. That means for a rails update you will only need one ring: update all gems and then let the scheduler calculate if all-good can be expanded or if something misses dependencies. (all-good has a script to update the buildrequires if you had new gems) As some gems require specific but old versions of other gems, I created (DISCLAIMER: careful, do not read further if you're easy to upset) a package containing all those gems. This package will build rpms for all gems in the source directory. While fixing the current dependencies, I found 33 gems that I didn't feel worthy enough for their own spec file, so they ended up in d:l:r:e/all-the-others. It should be noted, that all the gems in there are of course tabu for factory submission. If you need a dependency in factory, create a spec file and dig out the license, gems are pretty bad in specifying the license in .gemspec, so most gem2rpm generated spec files have the CHECK(Ruby) license (even though most I found in practice have MIT). As digging out the license is pretty boring work you don't want to do another time when updating the package, I changed gem2rpm to take the license from the output file in case there is no license in the gemspec. This makes it possible to update to a newer version for gems pretty easy: gem2rpm *.gem -o *.spec. Whenever a spec file needs manual adaption, I add a MANUAL comment in there, so you spot in a diff very easy that you need to check e.g. an extra buildrequire or some file list manipulation. If the week had more days, I think I would put the whole %package and %files sections in a macro, so that we can (later) have ruby20 and ruby19 in parallel. If the requires are automatic and the buildrequires nonexistant, it's basically about the %files sections. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Quoting Stephan Kulow <coolo@suse.de>:
Hi,
Want to know what I did for #hackweek8? I pulled ruby packaging apart and put it back together.
I... - split ruby-common from the ruby package, so it can also be used from ruby 1.8 distros - added patched rpms to devel:languages:ruby:backports for older distros to support overwriting macros and ruby dependencies (11.4 and sle11) - enhanced the %gem_install macro - wrote a gemspec to rpm converter to have requires and provides in rpm automatic without gem2rpm run - changed the gem2rpm template heavily
The key idea behind my work was that creating gem.rpm with gem2rpm is easy, updating is problematic (and over half the gems in dlre being outdated kind of proves my point :)
So the new template has no requires and no provides, because rpm can find out both from the installed .gemspec. E.g. I found a couple of cases that left broken provides with an update (e.g. 0.8.X providing _0_7). But this strange suffixing is no longer necessary anyway.
E.g. rails-3_2 has these automatic requires now:
ruby(abi) = 1.9.1 rubygem(1.9.1:actionmailer) = 3.2.7 rubygem(1.9.1:actionpack) = 3.2.7 rubygem(1.9.1:activerecord) = 3.2.7 rubygem(1.9.1:activeresource) = 3.2.7 rubygem(1.9.1:activesupport) = 3.2.7 rubygem(1.9.1:bundler) >= 1.0 rubygem(1.9.1:bundler) < 2 rubygem(1.9.1:railties) = 3.2.7
No more bundler-1_0, but a simple bundler < 2.
The automatic provides cover the old names, but I kind of hope we can drop them in the future:
rubygem(1.9.1:rails) = 3.2.7 rubygem(rails) = 3.2.7 rubygem-rails = 3.2.7 rubygem-rails-3 = 3.2.7 rubygem-rails-3_2 = 3.2.7 rubygem-rails-3_2_7 = 3.2.7
I do not generate buildrequires in the template either, even though this is a rather tough call.
We need buildrequires mainly to check that the dependencies are in the repo, but they create several problems: - gems build in "rings" and require a finished -> succeeded step for every ring, a rails update are 4 such rings. YOU GET CRAZY if the obs is busy! - you can't rely on automatism as the gem specificies "rails > 1.0", but there are 4 such rails versions and the build service wants to know which one you mean. And in case the rails version requires a rack > 1.1, it wants to know which one of those. YOU GET CRAZY!
As gem packaging has to be 99% automatic to compete with out of rpm gem, I went for calling gem install with -f and ignore buildignores.
To have a way to check dependencies in OBS, I created a small package called "all-good", that itself buildrequires all gems in the repository. That means for a rails update you will only need one ring: update all gems and then let the scheduler calculate if all-good can be expanded or if something misses dependencies. (all-good has a script to update the buildrequires if you had new gems)
As some gems require specific but old versions of other gems, I created (DISCLAIMER: careful, do not read further if you're easy to upset) a package containing all those gems. This package will build rpms for all gems in the source directory. While fixing the current dependencies, I found 33 gems that I didn't feel worthy enough for their own spec file, so they ended up in d:l:r:e/all-the-others.
It should be noted, that all the gems in there are of course tabu for factory submission. If you need a dependency in factory, create a spec file and dig out the license, gems are pretty bad in specifying the license in .gemspec, so most gem2rpm generated spec files have the CHECK(Ruby) license (even though most I found in practice have MIT).
As digging out the license is pretty boring work you don't want to do another time when updating the package, I changed gem2rpm to take the license from the output file in case there is no license in the gemspec.
This makes it possible to update to a newer version for gems pretty easy: gem2rpm *.gem -o *.spec.
Whenever a spec file needs manual adaption, I add a MANUAL comment in there, so you spot in a diff very easy that you need to check e.g. an extra buildrequire or some file list manipulation.
If the week had more days, I think I would put the whole %package and %files sections in a macro, so that we can (later) have ruby20 and ruby19 in parallel. If the requires are automatic and the buildrequires nonexistant, it's basically about the %files sections.
Greetings, Stephan
Hi Stephan, I tried to use the ruby rpm from d:l:r repo for building puppet (a copy from systemsmanagement:puppet puppet) and I got the following error: nothing provides rpm-with-ruby-provide-hook needed by ruby-common However, by using revision #41 (before hack week) it does build. I am building puppet for SLE_11_SP2.
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Mon, 30 Jul 2012 18:40:39 +0200 Jordi Massaguer Pla <jmassaguerpla@suse.de> wrote:
Quoting Stephan Kulow <coolo@suse.de>:
Hi,
Want to know what I did for #hackweek8? I pulled ruby packaging apart and put it back together.
I... - split ruby-common from the ruby package, so it can also be used from ruby 1.8 distros - added patched rpms to devel:languages:ruby:backports for older distros to support overwriting macros and ruby dependencies (11.4 and sle11) - enhanced the %gem_install macro - wrote a gemspec to rpm converter to have requires and provides in rpm automatic without gem2rpm run - changed the gem2rpm template heavily
The key idea behind my work was that creating gem.rpm with gem2rpm is easy, updating is problematic (and over half the gems in dlre being outdated kind of proves my point :)
So the new template has no requires and no provides, because rpm can find out both from the installed .gemspec. E.g. I found a couple of cases that left broken provides with an update (e.g. 0.8.X providing _0_7). But this strange suffixing is no longer necessary anyway.
E.g. rails-3_2 has these automatic requires now:
ruby(abi) = 1.9.1 rubygem(1.9.1:actionmailer) = 3.2.7 rubygem(1.9.1:actionpack) = 3.2.7 rubygem(1.9.1:activerecord) = 3.2.7 rubygem(1.9.1:activeresource) = 3.2.7 rubygem(1.9.1:activesupport) = 3.2.7 rubygem(1.9.1:bundler) >= 1.0 rubygem(1.9.1:bundler) < 2 rubygem(1.9.1:railties) = 3.2.7
No more bundler-1_0, but a simple bundler < 2.
The automatic provides cover the old names, but I kind of hope we can drop them in the future:
rubygem(1.9.1:rails) = 3.2.7 rubygem(rails) = 3.2.7 rubygem-rails = 3.2.7 rubygem-rails-3 = 3.2.7 rubygem-rails-3_2 = 3.2.7 rubygem-rails-3_2_7 = 3.2.7
I do not generate buildrequires in the template either, even though this is a rather tough call.
We need buildrequires mainly to check that the dependencies are in the repo, but they create several problems: - gems build in "rings" and require a finished -> succeeded step for every ring, a rails update are 4 such rings. YOU GET CRAZY if the obs is busy! - you can't rely on automatism as the gem specificies "rails > 1.0", but there are 4 such rails versions and the build service wants to know which one you mean. And in case the rails version requires a rack > 1.1, it wants to know which one of those. YOU GET CRAZY!
As gem packaging has to be 99% automatic to compete with out of rpm gem, I went for calling gem install with -f and ignore buildignores.
To have a way to check dependencies in OBS, I created a small package called "all-good", that itself buildrequires all gems in the repository. That means for a rails update you will only need one ring: update all gems and then let the scheduler calculate if all-good can be expanded or if something misses dependencies. (all-good has a script to update the buildrequires if you had new gems)
As some gems require specific but old versions of other gems, I created (DISCLAIMER: careful, do not read further if you're easy to upset) a package containing all those gems. This package will build rpms for all gems in the source directory. While fixing the current dependencies, I found 33 gems that I didn't feel worthy enough for their own spec file, so they ended up in d:l:r:e/all-the-others.
It should be noted, that all the gems in there are of course tabu for factory submission. If you need a dependency in factory, create a spec file and dig out the license, gems are pretty bad in specifying the license in .gemspec, so most gem2rpm generated spec files have the CHECK(Ruby) license (even though most I found in practice have MIT).
As digging out the license is pretty boring work you don't want to do another time when updating the package, I changed gem2rpm to take the license from the output file in case there is no license in the gemspec.
This makes it possible to update to a newer version for gems pretty easy: gem2rpm *.gem -o *.spec.
Whenever a spec file needs manual adaption, I add a MANUAL comment in there, so you spot in a diff very easy that you need to check e.g. an extra buildrequire or some file list manipulation.
If the week had more days, I think I would put the whole %package and %files sections in a macro, so that we can (later) have ruby20 and ruby19 in parallel. If the requires are automatic and the buildrequires nonexistant, it's basically about the %files sections.
Greetings, Stephan
Hi Stephan,
I tried to use the ruby rpm from d:l:r repo for building puppet (a copy from systemsmanagement:puppet puppet) and I got the following error:
nothing provides rpm-with-ruby-provide-hook needed by ruby-common
However, by using revision #41 (before hack week) it does build.
I am building puppet for SLE_11_SP2.
Hi, you need rpm from d:l:r:b ( backports ). We are now in discussion to port such fix for rpm as update in SP2. Josef
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Am 30.07.2012 19:02, schrieb Josef Reidinger:
I tried to use the ruby rpm from d:l:r repo for building puppet (a copy from systemsmanagement:puppet puppet) and I got the following error:
nothing provides rpm-with-ruby-provide-hook needed by ruby-common
However, by using revision #41 (before hack week) it does build.
I am building puppet for SLE_11_SP2.
Hi, you need rpm from d:l:r:b ( backports ). We are now in discussion to port such fix for rpm as update in SP2.
You can add that as path to your project's meta Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Mon, 30 Jul 2012 15:22:34 +0200 Stephan Kulow <coolo@suse.de> wrote:
Hi,
Want to know what I did for #hackweek8? I pulled ruby packaging apart and put it back together.
I... - split ruby-common from the ruby package, so it can also be used from ruby 1.8 distros - added patched rpms to devel:languages:ruby:backports for older distros to support overwriting macros and ruby dependencies (11.4 and sle11) - enhanced the %gem_install macro - wrote a gemspec to rpm converter to have requires and provides in rpm automatic without gem2rpm run - changed the gem2rpm template heavily
I play with it now when I try to get working webyast and SLMS with new gems and I found it really cool. Good work. One disadvantage is that all dependencies need to be generated by new gem2rpm. I convert a lot of gems in dlre, but more maybe will be needed.
The key idea behind my work was that creating gem.rpm with gem2rpm is easy, updating is problematic (and over half the gems in dlre being outdated kind of proves my point :)
So the new template has no requires and no provides, because rpm can find out both from the installed .gemspec. E.g. I found a couple of cases that left broken provides with an update (e.g. 0.8.X providing _0_7). But this strange suffixing is no longer necessary anyway.
E.g. rails-3_2 has these automatic requires now:
ruby(abi) = 1.9.1 rubygem(1.9.1:actionmailer) = 3.2.7 rubygem(1.9.1:actionpack) = 3.2.7 rubygem(1.9.1:activerecord) = 3.2.7 rubygem(1.9.1:activeresource) = 3.2.7 rubygem(1.9.1:activesupport) = 3.2.7 rubygem(1.9.1:bundler) >= 1.0 rubygem(1.9.1:bundler) < 2 rubygem(1.9.1:railties) = 3.2.7
No more bundler-1_0, but a simple bundler < 2.
The automatic provides cover the old names, but I kind of hope we can drop them in the future:
Please do not drop it in near future, as we use recent gems in ATK and part of gems is also in SDK, so we want to be backward compatible if customer create ruby/rails rpm with old dependencies.
rubygem(1.9.1:rails) = 3.2.7 rubygem(rails) = 3.2.7 rubygem-rails = 3.2.7 rubygem-rails-3 = 3.2.7 rubygem-rails-3_2 = 3.2.7 rubygem-rails-3_2_7 = 3.2.7
I do not generate buildrequires in the template either, even though this is a rather tough call.
We need buildrequires mainly to check that the dependencies are in the repo, but they create several problems: - gems build in "rings" and require a finished -> succeeded step for every ring, a rails update are 4 such rings. YOU GET CRAZY if the obs is busy! - you can't rely on automatism as the gem specificies "rails > 1.0", but there are 4 such rails versions and the build service wants to know which one you mean. And in case the rails version requires a rack > 1.1, it wants to know which one of those. YOU GET CRAZY!
As gem packaging has to be 99% automatic to compete with out of rpm gem, I went for calling gem install with -f and ignore buildignores.
Yes, it is reasonable and helps with speed up of build.
To have a way to check dependencies in OBS, I created a small package called "all-good", that itself buildrequires all gems in the repository. That means for a rails update you will only need one ring: update all gems and then let the scheduler calculate if all-good can be expanded or if something misses dependencies. (all-good has a script to update the buildrequires if you had new gems)
We use for testing target rails appliance, that have rpm with requirements.
As some gems require specific but old versions of other gems, I created (DISCLAIMER: careful, do not read further if you're easy to upset) a package containing all those gems. This package will build rpms for all gems in the source directory. While fixing the current dependencies, I found 33 gems that I didn't feel worthy enough for their own spec file, so they ended up in d:l:r:e/all-the-others.
I think we need to create policy for such packages. Example is factory_girl, where I create old version because new one doesn't work with ruby 1.9. I think that plain name should be always latest version and create suffix only if you need old version. I use copypac with specific revision and looks working for me. Josef
It should be noted, that all the gems in there are of course tabu for factory submission. If you need a dependency in factory, create a spec file and dig out the license, gems are pretty bad in specifying the license in .gemspec, so most gem2rpm generated spec files have the CHECK(Ruby) license (even though most I found in practice have MIT).
As digging out the license is pretty boring work you don't want to do another time when updating the package, I changed gem2rpm to take the license from the output file in case there is no license in the gemspec.
This makes it possible to update to a newer version for gems pretty easy: gem2rpm *.gem -o *.spec.
Whenever a spec file needs manual adaption, I add a MANUAL comment in there, so you spot in a diff very easy that you need to check e.g. an extra buildrequire or some file list manipulation.
If the week had more days, I think I would put the whole %package and %files sections in a macro, so that we can (later) have ruby20 and ruby19 in parallel. If the requires are automatic and the buildrequires nonexistant, it's basically about the %files sections.
Greetings, Stephan
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 01.08.2012 10:08, Josef Reidinger wrote:
- changed the gem2rpm template heavily
I play with it now when I try to get working webyast and SLMS with new gems and I found it really cool. Good work. One disadvantage is that all dependencies need to be generated by new gem2rpm. I convert a lot of gems in dlre, but more maybe will be needed.
It's not strictly necessary to regenerate them. But you need to have the buildrequires ruby-macros in there (it's required when building against devel:languages:ruby:backports, but I guess you don't build in dlre yourself).
The automatic provides cover the old names, but I kind of hope we can drop them in the future:
Please do not drop it in near future, as we use recent gems in ATK and part of gems is also in SDK, so we want to be backward compatible if customer create ruby/rails rpm with old dependencies.
How long do you think our factory ruby needs to be backward compatible with sle11 customer? Another 10 years?
As some gems require specific but old versions of other gems, I created (DISCLAIMER: careful, do not read further if you're easy to upset) a package containing all those gems. This package will build rpms for all gems in the source directory. While fixing the current dependencies, I found 33 gems that I didn't feel worthy enough for their own spec file, so they ended up in d:l:r:e/all-the-others.
I think we need to create policy for such packages. Example is factory_girl, where I create old version because new one doesn't work with ruby 1.9. I think that plain name should be always latest version and create suffix only if you need old version. I use copypac with specific revision and looks working for me.
I very much agree on the need of a policy. We should not use suffix for new packages. Perhaps make an exception for rails, but I already changed quite a few useless suffixes. Even worse is rubygem-thor where -thor is the old version and -thor-0_15 is the new version - I fixed that too. But: be careful with copypac - you screwed factory_girl actually because for a moment you had 2 rubygem-factory_girl.spec files building overwriting each other's rpms in the repository. And if you then later rename to factory_girl-2, you erase the rpms and then there is no factory_girl left. So if you copypac, build disable the new package quickly afterwards, then fix the package to get a good suffix and then build enable. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Wed, 01 Aug 2012 10:18:36 +0200 Stephan Kulow <coolo@suse.de> wrote:
On 01.08.2012 10:08, Josef Reidinger wrote:
- changed the gem2rpm template heavily
I play with it now when I try to get working webyast and SLMS with new gems and I found it really cool. Good work. One disadvantage is that all dependencies need to be generated by new gem2rpm. I convert a lot of gems in dlre, but more maybe will be needed.
It's not strictly necessary to regenerate them. But you need to have the buildrequires ruby-macros in there (it's required when building against devel:languages:ruby:backports, but I guess you don't build in dlre yourself).
The automatic provides cover the old names, but I kind of hope we can drop them in the future:
Please do not drop it in near future, as we use recent gems in ATK and part of gems is also in SDK, so we want to be backward compatible if customer create ruby/rails rpm with old dependencies.
How long do you think our factory ruby needs to be backward compatible with sle11 customer? Another 10 years?
As some gems require specific but old versions of other gems, I created (DISCLAIMER: careful, do not read further if you're easy to upset) a package containing all those gems. This package will build rpms for all gems in the source directory. While fixing the current dependencies, I found 33 gems that I didn't feel worthy enough for their own spec file, so they ended up in d:l:r:e/all-the-others.
I think we need to create policy for such packages. Example is factory_girl, where I create old version because new one doesn't work with ruby 1.9. I think that plain name should be always latest version and create suffix only if you need old version. I use copypac with specific revision and looks working for me.
I very much agree on the need of a policy. We should not use suffix for new packages. Perhaps make an exception for rails, but I already changed quite a few useless suffixes. Even worse is rubygem-thor where -thor is the old version and -thor-0_15 is the new version - I fixed that too.
But: be careful with copypac - you screwed factory_girl actually because for a moment you had 2 rubygem-factory_girl.spec files building overwriting each other's rpms in the repository. And if you then later rename to factory_girl-2, you erase the rpms and then there is no factory_girl left. So if you copypac, build disable the new package quickly afterwards, then fix the package to get a good suffix and then build enable.
Is there another way then copypac? link doesn't look suitable for me, as I want to diverge from original package and provide only maintenance fix for given branch. Josef
Greetings, Stephan
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 01.08.2012 10:27, Josef Reidinger wrote:
Is there another way then copypac? link doesn't look suitable for me, as I want to diverge from original package and provide only maintenance fix for given branch.
Just osc mkpac $newpack; cp $oldsources $newpack; osc ci $newpack Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Hi all, Stephan Kulow (coolo@suse.de) wrote:
On 01.08.2012 10:08, Josef Reidinger wrote:
As some gems require specific but old versions of other gems, I created (DISCLAIMER: careful, do not read further if you're easy to upset) a package containing all those gems. This package will build rpms for all gems in the source directory. While fixing the current dependencies, I found 33 gems that I didn't feel worthy enough for their own spec file, so they ended up in d:l:r:e/all-the-others.
I think we need to create policy for such packages. Example is factory_girl, where I create old version because new one doesn't work with ruby 1.9. I think that plain name should be always latest version and create suffix only if you need old version. I use copypac with specific revision and looks working for me.
I very much agree on the need of a policy. We should not use suffix for new packages. Perhaps make an exception for rails, but I already changed quite a few useless suffixes. Even worse is rubygem-thor where -thor is the old version and -thor-0_15 is the new version - I fixed that too.
+1 for the need of an up to date policy! I'm new to this list and also fairly new to packaging gems as rpms. I'm currently packaging Crowbar 2.0 for openSUSE 12.2 (which depends on Chef and Rails 3) and trying to resolve some gem dependencies. I've trawled the last ~15 months of archives of this list but I'm still unsure if there is currently a strong consensus on best practices. It seems that http://en.opensuse.org/openSUSE:Packaging_Ruby has barely been updated in that time, and does not explain current conventions on gem package naming and versioning. For example is it now firm policy to always use the "rubygem-${gem}-1_2-1.2.3" format in spec files which build or require older major versions, and "rubygem-${gem}-2.0.0" format for the latest major version? Are there any other important rules to be aware of? What about the rpm vs. bundle debate? Any best practice recommendations? Is it basically security and reusability (rpm) vs. simplicity and convenience (bundle)? Thanks, Adam P.S. I tried adding <path project="devel:languages:ruby:extensions" repository="openSUSE_12.2"/> to my project's metadata, but that broken everything horribly, so I'm currently relying on linkpac and intuition. Maybe I'll try again with systemsmanagement:chef. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Hi, using rpm to cripple a well working mechanism (gem/bundler) for Ruby feels wrong per se, but that's probably worth another discussion on opensuse-softwaremgmt. That said, the current solution of adding version numbers to package names seems awkward. RPM already provides dependency resolution based on names and version numbers, moving versions into the package name just seems to add more work on packagers and to pollute the package name space. Looks more like a workaround for build service limitations to me. 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
Klaus Kaempf (kkaempf@suse.de) wrote:
Hi,
using rpm to cripple a well working mechanism (gem/bundler) for Ruby feels wrong per se, but that's probably worth another discussion on opensuse-softwaremgmt.
When trawling this list's archives, it seemed to me that this discussion had already been mostly covered on this list. Another thing to bear in mind is that even though this is an openSUSE list, the reality is that rpm packaging of gems will in some contexts be done by SUSE employees and driven by the need for those rpms as part of the platform for a current or future SUSE product such as a release of SUSE Studio or Cloud. In that context, there *may* be more compelling reasons to have one rpm per gem than there would normally be, e.g. to conform with existing product maintenance mechanisms (security updates are the most obvious, but IIRC there are automated per-rpm licensing checks too and maybe other legalities which would probably be circumvented by shipping bundles instead). So the question is whether the additional effort in packaging is justified or not. Even if it is, of course this would not force any openSUSE user to use the rpms instead of bundler.
That said, the current solution of adding version numbers to package names seems awkward. RPM already provides dependency resolution based on names and version numbers, moving versions into the package name just seems to add more work on packagers and to pollute the package name space. Looks more like a workaround for build service limitations to me.
No, these are limitations in rpm itself. As darix pointed out last year, bundler's ~> operator cannot map straightforwardly into rpm Requires expressions: http://lists.opensuse.org/opensuse-ruby/2011-07/msg00000.html -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Am 25.10.2012 16:42, schrieb Adam Spiers:
No, these are limitations in rpm itself. As darix pointed out last year, bundler's ~> operator cannot map straightforwardly into rpm Requires expressions:
http://lists.opensuse.org/opensuse-ruby/2011-07/msg00000.html
Yeah, but that information is outdated - if you read the thread a year later: http://lists.opensuse.org/opensuse-ruby/2012-07/msg00025.html So the policy we live is this: we package <gem> as rubygem-<gem> and only add a version suffix only if something requires an old version of <gem> (and then only to the old version) or if <gem> is <rails> - for historical reasons :) We didn't rename all gem_1_0 packages yet, but we're going there whenever we update a package. 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> [Oct 25. 2012 16:49]:
Am 25.10.2012 16:42, schrieb Adam Spiers:
No, these are limitations in rpm itself. As darix pointed out last year, bundler's ~> operator cannot map straightforwardly into rpm Requires expressions:
http://lists.opensuse.org/opensuse-ruby/2011-07/msg00000.html
Yeah, but that information is outdated - if you read the thread a year later: http://lists.opensuse.org/opensuse-ruby/2012-07/msg00025.html
This still doesn't explain the need to tack version numbers to RPM package names. This seems a requirement from OBS (inability to build multiple version of the same package name), not from RPM !? 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
Klaus Kaempf (kkaempf@suse.de) wrote:
* Stephan Kulow <coolo@suse.de> [Oct 25. 2012 16:49]:
Am 25.10.2012 16:42, schrieb Adam Spiers:
No, these are limitations in rpm itself. As darix pointed out last year, bundler's ~> operator cannot map straightforwardly into rpm Requires expressions:
http://lists.opensuse.org/opensuse-ruby/2011-07/msg00000.html
Yeah, but that information is outdated - if you read the thread a year later: http://lists.opensuse.org/opensuse-ruby/2012-07/msg00025.html
This still doesn't explain the need to tack version numbers to RPM package names. This seems a requirement from OBS (inability to build multiple version of the same package name), not from RPM !?
Yeah I guess you're right (and as per my other mail, virtual packages of the format rubygem-foo-1_1 seem to allow mapping of the ~> operator anyway). Stupid question: does OBS require that the package name matches the .spec filename, and/or the Name: field inside the spec file? Or could you have for example $project/rubygem-foo-1.0/rubygem-foo-1.0.spec which contains Name: rubygem-foo Version: 1.0 ? If this is allowed, maybe you could have $project/rubygem-foo-1.1/rubygem-foo-1.1.spec in the same OBS project which contains Name: rubygem-foo Version: 1.1 and they would both get built? If this is not allowed, maybe the restriction could be worked around by simply putting the older versions in separate projects. A project per old gem is very heavyweight; an alternative might be devel:languages:ruby:extension devel:languages:ruby:extension:old devel:languages:ruby:extension:older devel:languages:ruby:extension:oldest or similar which is *very* ugly but would at least allow a maximum of 4 different versions of the same gem with less overhead. However that may have unwanted repercussions on dependency resolution ... Thanks, Adam -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Adam Spiers <aspiers@suse.com> [Oct 30. 2012 18:05]:
Stupid question: does OBS require that the package name matches the .spec filename, and/or the Name: field inside the spec file?
Afaik neither. I usually have the project name match the .spec file name only.
Or could you have for example
$project/rubygem-foo-1.0/rubygem-foo-1.0.spec
which contains
Name: rubygem-foo Version: 1.0
?
If this is allowed, maybe you could have
$project/rubygem-foo-1.1/rubygem-foo-1.1.spec
in the same OBS project which contains
Name: rubygem-foo Version: 1.1
and they would both get built?
Yes. I'm using this for example to build multiple versions of sblim-sfcb in systemsmanagement:wbem for openSUSE_12.1. http://download.opensuse.org/repositories/systemsmanagement:/wbem/openSUSE_1... contains sblim-sfcb in version 1.3.7, 1.3.11, 1.3.15 and 1.4.2 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
Klaus Kaempf (kkaempf@suse.de) wrote:
* Adam Spiers <aspiers@suse.com> [Oct 30. 2012 18:05]:
Stupid question: does OBS require that the package name matches the .spec filename, and/or the Name: field inside the spec file?
Afaik neither. I usually have the project name match the .spec file name only.
Or could you have for example
$project/rubygem-foo-1.0/rubygem-foo-1.0.spec
which contains
Name: rubygem-foo Version: 1.0
?
If this is allowed, maybe you could have
$project/rubygem-foo-1.1/rubygem-foo-1.1.spec
in the same OBS project which contains
Name: rubygem-foo Version: 1.1
and they would both get built?
Yes. I'm using this for example to build multiple versions of sblim-sfcb in systemsmanagement:wbem for openSUSE_12.1.
http://download.opensuse.org/repositories/systemsmanagement:/wbem/openSUSE_1... contains sblim-sfcb in version 1.3.7, 1.3.11, 1.3.15 and 1.4.2
Ah, that's handy. So if the OBS does not have a limitation on multiple versions of a package co-existing in a single project, I'm even more mystified why there was ever a need to introduce the Name: rubygem-foo-1_1 style of naming ... -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Am 02.11.2012 13:40, schrieb Adam Spiers:
Ah, that's handy. So if the OBS does not have a limitation on multiple versions of a package co-existing in a single project, I'm even more mystified why there was ever a need to introduce the
Name: rubygem-foo-1_1
style of naming ...
Because that was used to implement foo ~> 1.1.2 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) wrote:
Am 02.11.2012 13:40, schrieb Adam Spiers:
Ah, that's handy. So if the OBS does not have a limitation on multiple versions of a package co-existing in a single project, I'm even more mystified why there was ever a need to introduce the
Name: rubygem-foo-1_1
style of naming ...
Because that was used to implement foo ~> 1.1.2
But isn't that already supported via the automatic provides: Provides: rubygem-foo-1_1 = 1.1.3 and the corresponding automatic requires: Requires: rubygem-foo-1_1 >= 1.1.2 ? Is it just a historical thing which happened before your revamp introduced the automatic provides/requires? -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 03.11.2012 15:01, Adam Spiers wrote:
Stephan Kulow (coolo@suse.de) wrote:
Am 02.11.2012 13:40, schrieb Adam Spiers:
Ah, that's handy. So if the OBS does not have a limitation on multiple versions of a package co-existing in a single project, I'm even more mystified why there was ever a need to introduce the
Name: rubygem-foo-1_1
style of naming ...
Because that was used to implement foo ~> 1.1.2
But isn't that already supported via the automatic provides:
Provides: rubygem-foo-1_1 = 1.1.3
and the corresponding automatic requires:
Requires: rubygem-foo-1_1 >= 1.1.2
There is no such automatic requires. The provides are just for old packages that still have the requires in their spec file. 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) wrote:
On 03.11.2012 15:01, Adam Spiers wrote:
Stephan Kulow (coolo@suse.de) wrote:
Am 02.11.2012 13:40, schrieb Adam Spiers:
Ah, that's handy. So if the OBS does not have a limitation on multiple versions of a package co-existing in a single project, I'm even more mystified why there was ever a need to introduce the
Name: rubygem-foo-1_1
style of naming ...
Because that was used to implement foo ~> 1.1.2
But isn't that already supported via the automatic provides:
Provides: rubygem-foo-1_1 = 1.1.3
and the corresponding automatic requires:
Requires: rubygem-foo-1_1 >= 1.1.2
There is no such automatic requires.
It would have been more helpful to say which requires *are* automatic, or even better to document how all this works in the wiki instead of wasting both our time with all my stupid questions :-/ Your original post said "wrote a gemspec to rpm converter to have requires and provides in rpm automatic without gem2rpm run" but didn't say where this mechanism lives. Eventually I tracked it down to /usr/lib/rpm/{rubygemsdeps.rb,fileattrs/rubygems.attr} in ruby-common from devel:languages:ruby, so now I can see for myself how it works. I updated http://en.opensuse.org/openSUSE:Packaging_Ruby accordingly. However there is still an unresolved issue: ruby-common-1.9.3 is provided by the main 12.2 OSS repo, which overrides ruby-common-1.0 from d:l:r. So when I try to build from a .spec generated by gem2rpm, it fails with: unresolvable: nothing provides ruby-macros >= 1, nothing provides rubygem(rdoc) > 3.10 Here is the context: $ osc buildinfo openSUSE_12.2 <buildinfo project="systemsmanagement:crowbar:2.0" repository="openSUSE_12.2" package="rubygem-rainbows" downloadurl="http://download.opensuse.org/repositories"> <arch>x86_64</arch> <error>unresolvable: nothing provides ruby-macros >= 1, nothing provides rubygem(rdoc) > 3.10</error> <debuginfo>0</debuginfo> <subpack>rubygem-rainbows</subpack> <subpack>rubygem-rainbows-doc</subpack> <path project="systemsmanagement:crowbar:2.0" repository="openSUSE_12.2" /> <path project="openSUSE:12.2" repository="standard" /> <path project="systemsmanagement:chef" repository="openSUSE_12.2" /> <path project="devel:languages:ruby" repository="openSUSE_12.2" /> </buildinfo> How do I fix that? -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 05.11.2012 14:15, Adam Spiers wrote:
Here is the context:
$ osc buildinfo openSUSE_12.2 <buildinfo project="systemsmanagement:crowbar:2.0" repository="openSUSE_12.2" package="rubygem-rainbows" downloadurl="http://download.opensuse.org/repositories"> <arch>x86_64</arch> <error>unresolvable: nothing provides ruby-macros >= 1, nothing provides rubygem(rdoc) > 3.10</error> <debuginfo>0</debuginfo> <subpack>rubygem-rainbows</subpack> <subpack>rubygem-rainbows-doc</subpack> <path project="systemsmanagement:crowbar:2.0" repository="openSUSE_12.2" /> <path project="openSUSE:12.2" repository="standard" /> <path project="systemsmanagement:chef" repository="openSUSE_12.2" /> <path project="devel:languages:ruby" repository="openSUSE_12.2" /> </buildinfo>
How do I fix that?
Do not build directly against 12.2. Having two paths in a repository only makes sense if they provide things that are 100% exclusive to each other. In your case they are not as :chef overlays things from 12.2 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) wrote:
On 05.11.2012 14:15, Adam Spiers wrote:
Here is the context:
$ osc buildinfo openSUSE_12.2 <buildinfo project="systemsmanagement:crowbar:2.0" repository="openSUSE_12.2" package="rubygem-rainbows" downloadurl="http://download.opensuse.org/repositories"> <arch>x86_64</arch> <error>unresolvable: nothing provides ruby-macros >= 1, nothing provides rubygem(rdoc) > 3.10</error> <debuginfo>0</debuginfo> <subpack>rubygem-rainbows</subpack> <subpack>rubygem-rainbows-doc</subpack> <path project="systemsmanagement:crowbar:2.0" repository="openSUSE_12.2" /> <path project="openSUSE:12.2" repository="standard" /> <path project="systemsmanagement:chef" repository="openSUSE_12.2" /> <path project="devel:languages:ruby" repository="openSUSE_12.2" /> </buildinfo>
How do I fix that?
Do not build directly against 12.2. Having two paths in a repository only makes sense if they provide things that are 100% exclusive to each other. In your case they are not as :chef overlays things from 12.2
Ahh!! Thanks a lot :-) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Adam Spiers (aspiers@suse.com) wrote:
Stephan Kulow (coolo@suse.de) wrote:
Am 02.11.2012 13:40, schrieb Adam Spiers:
Ah, that's handy. So if the OBS does not have a limitation on multiple versions of a package co-existing in a single project, I'm even more mystified why there was ever a need to introduce the
Name: rubygem-foo-1_1
style of naming ...
Because that was used to implement foo ~> 1.1.2
But isn't that already supported via the automatic provides:
[snipped inaccurate example of automatic provides]
and the corresponding automatic requires:
[snipped inaccurate example of automatic requires]
?
Is it just a historical thing which happened before your revamp introduced the automatic provides/requires?
OK, so I now know what the automatic provides/requires really look like, but I still haven't heard an answer why the naming scheme 'Name: rubygem-foo-1_1' was ever used, when Requires/Provides of symbols achieved the same thing. And the following is not 100% clear to me either: Stephan Kulow (coolo@suse.de) wrote:
So the policy we live is this: we package <gem> as rubygem-<gem> and only add a version suffix only if something requires an old version of <gem> (and then only to the old version) or if <gem> is <rails> - for historical reasons :)
Add a version suffix to what - the Name: field of the old version of the gem being required? If so, why not just use symbols?
We didn't rename all gem_1_0 packages yet, but we're going there whenever we update a package.
OK, so this needs to be part of the policy too. I'd like to understand all this fully so I can document it in http://en.opensuse.org/openSUSE:Packaging_Ruby It's not enough for this wiki page to document the current (latest) versioning schemes - the old versioning schemes existing in several repositories, and will continue to cause confusion for people like me unless we document a summary of the history behind the changes. I don't want other people to have to waste as much time on this as I have. Thanks, Adam -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 05.11.2012 14:31, Adam Spiers wrote:
Is it just a historical thing which happened before your revamp introduced the automatic provides/requires?
OK, so I now know what the automatic provides/requires really look like, but I still haven't heard an answer why the naming scheme 'Name: rubygem-foo-1_1' was ever used, when Requires/Provides of symbols achieved the same thing.
I already gave it to you: it was used to implement the ~> operator without touching rpm.
And the following is not 100% clear to me either:
Stephan Kulow (coolo@suse.de) wrote:
So the policy we live is this: we package <gem> as rubygem-<gem> and only add a version suffix only if something requires an old version of <gem> (and then only to the old version) or if <gem> is <rails> - for historical reasons :)
Add a version suffix to what - the Name: field of the old version of the gem being required? If so, why not just use symbols?
No, the suffix is only there to avoid clashes between two .rpm files. You can't have rubygem-<gem> twice in the build service. So once of them needs to have rubygem-<gem>-<version_part> and the (new) policy is that this one is the old one.
It's not enough for this wiki page to document the current (latest) versioning schemes - the old versioning schemes existing in several repositories, and will continue to cause confusion for people like me unless we document a summary of the history behind the changes. I don't want other people to have to waste as much time on this as I have.
Hmm, isn't having the history next to the state confusing too? 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> [Nov 05. 2012 14:41]:
No, the suffix is only there to avoid clashes between two .rpm files. You can't have rubygem-<gem> twice in the build service.
Where can I file feature (bug ?) reports against the build service ? (SCNR!) Then I'd advocate to keep the version suffix in the build service package name (to work around the above mentioned build service bug) This should then allow us to have multiple versions of the same (ruby)gem in a build service project. Example: d:l:r:e/rubygem-foo-1_0 (-> builds rubygem-foo-1.0) foo-1.0.gem rubygem-foo.spec rubygem-foo.changes d:l:r:e/rubygem-foo-1_1 (-> builds rubygem-foo-1.0) foo-1.1.gem rubygem-foo.spec rubygem-foo.changes Note: the version suffix is only in the build service name, not in the .spec, .changes, or .rpm file. 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
Klaus Kaempf (kkaempf@suse.de) wrote:
* Stephan Kulow <coolo@suse.de> [Nov 05. 2012 14:41]:
No, the suffix is only there to avoid clashes between two .rpm files. You can't have rubygem-<gem> twice in the build service.
Where can I file feature (bug ?) reports against the build service ? (SCNR!)
Then I'd advocate to keep the version suffix in the build service package name (to work around the above mentioned build service bug)
I don't understand what the bug is? It already seems to work fine in the example you cited: https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp1&project=systemsmanagement%3Awbem https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp2&project=systemsmanagement%3Awbem
This should then allow us to have multiple versions of the same (ruby)gem in a build service project.
Example:
d:l:r:e/rubygem-foo-1_0 (-> builds rubygem-foo-1.0) foo-1.0.gem rubygem-foo.spec rubygem-foo.changes
d:l:r:e/rubygem-foo-1_1 (-> builds rubygem-foo-1.0)
I assume you meant rubygem-foo-1.1 there?
foo-1.1.gem rubygem-foo.spec rubygem-foo.changes
Note: the version suffix is only in the build service name, not in the .spec, .changes, or .rpm file.
Isn't that exactly what you did for sblim-sfcb above? Is there a particular reason why this wouldn't work for gem packages? Confused ... again ;-) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Am 05.11.2012 19:54, schrieb Adam Spiers:
Klaus Kaempf (kkaempf@suse.de) wrote:
* Stephan Kulow <coolo@suse.de> [Nov 05. 2012 14:41]:
No, the suffix is only there to avoid clashes between two .rpm files. You can't have rubygem-<gem> twice in the build service.
Where can I file feature (bug ?) reports against the build service ? (SCNR!)
Then I'd advocate to keep the version suffix in the build service package name (to work around the above mentioned build service bug)
I don't understand what the bug is? It already seems to work fine in the example you cited:
https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp1&project=systemsmanagement%3Awbem https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp2&project=systemsmanagement%3Awbem
Well, what will happen if you buildrequire sblim-sfcb? I can tell you: the last built rpm will win -> not good, especially if it's important that the rpm has a specific version. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Mon, 05 Nov 2012 20:13:27 +0100 Stephan Kulow <coolo@suse.de> wrote:
Am 05.11.2012 19:54, schrieb Adam Spiers:
Klaus Kaempf (kkaempf@suse.de) wrote:
* Stephan Kulow <coolo@suse.de> [Nov 05. 2012 14:41]:
No, the suffix is only there to avoid clashes between two .rpm files. You can't have rubygem-<gem> twice in the build service.
Where can I file feature (bug ?) reports against the build service ? (SCNR!)
Then I'd advocate to keep the version suffix in the build service package name (to work around the above mentioned build service bug)
I don't understand what the bug is? It already seems to work fine in the example you cited:
https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp1&project=systemsmanagement%3Awbem https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp2&project=systemsmanagement%3Awbem
Well, what will happen if you buildrequire sblim-sfcb? I can tell you: the last built rpm will win -> not good, especially if it's important that the rpm has a specific version.
Greetings, Stephan
buildrequire doesn't allow to specify version? if you need specific version, then you should specify it. Josef -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Am 05.11.2012 20:40, schrieb Josef Reidinger:
buildrequire doesn't allow to specify version? if you need specific version, then you should specify it.
Of course they do, but as I tried to explain several times now: there can only be one rubygem-foo in OBS if you want to build against it. 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> [Nov 05. 2012 20:47]:
Am 05.11.2012 20:40, schrieb Josef Reidinger:
buildrequire doesn't allow to specify version? if you need specific version, then you should specify it.
Of course they do, but as I tried to explain several times now: there can only be one rubygem-foo in OBS if you want to build against it.
I'll try this with sblim-sfcb in systemsmanagement:wbem. I'd consider this a MAJOR bug. 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
Am 05.11.2012 21:12, schrieb Klaus Kaempf:
* Stephan Kulow <coolo@suse.de> [Nov 05. 2012 20:47]:
Am 05.11.2012 20:40, schrieb Josef Reidinger:
buildrequire doesn't allow to specify version? if you need specific version, then you should specify it.
Of course they do, but as I tried to explain several times now: there can only be one rubygem-foo in OBS if you want to build against it.
I'll try this with sblim-sfcb in systemsmanagement:wbem. I'd consider this a MAJOR bug.
It's not a bug, it's a design limitation. BTW: zypper doesn't like two packages named rubygem-foo either. 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> [Nov 06. 2012 06:43]:
It's not a bug, it's a design limitation.
LOL
BTW: zypper doesn't like two packages named rubygem-foo either.
Can you please be more specific here ? zypper is supporting multiple versions of a package (i.e. the linux kernel) for quite some time and I don't see issues with zypper and the four versions of sblim-sfcb in systemsmanagement:wbem either. 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 06.11.2012 09:54, Klaus Kaempf wrote:
* Stephan Kulow <coolo@suse.de> [Nov 06. 2012 06:43]:
It's not a bug, it's a design limitation.
LOL
BTW: zypper doesn't like two packages named rubygem-foo either.
Can you please be more specific here ?
zypper is supporting multiple versions of a package (i.e. the linux kernel) for quite some time and I don't see issues with zypper and the four versions of sblim-sfcb in systemsmanagement:wbem either.
Yeah, if you configure multiversion for kernels in zypp.conf - do you want to change zypp.conf for all 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) wrote:
On 06.11.2012 09:54, Klaus Kaempf wrote:
* Stephan Kulow <coolo@suse.de> [Nov 06. 2012 06:43]:
It's not a bug, it's a design limitation.
LOL
BTW: zypper doesn't like two packages named rubygem-foo either.
Can you please be more specific here ?
zypper is supporting multiple versions of a package (i.e. the linux kernel) for quite some time and I don't see issues with zypper and the four versions of sblim-sfcb in systemsmanagement:wbem either.
Yeah, if you configure multiversion for kernels in zypp.conf - do you want to change zypp.conf for all gems?
multiversion is not necessarily a requirement here. We are talking about a single OBS project providing the *choice* of multiple versions of a gem. AFAICS, sblim-sfcb in systemsmanagement:wbem is an example where multiversion would *not* be required, because e.g. 1.3.7 would only ever be installed on SP1 machines, and 1.3.11 on SP2 machines. However, in the few ugly cases where multi-version is required, it should be possible to accommodate - rubygemsdeps.rb could generate the following extra Provides: multiversion(rubygem) multiversion(rubygem-foo) multiversion(rubygem-foo-1) multiversion(rubygem-foo-1_2) multiversion(1.9:rubygem-foo) multiversion(1.9:rubygem-foo-1) multiversion(1.9:rubygem-foo-1_2) and then any product-oriented rpm could install the appropriate multiversion policy / policies into /etc/zypp/multiversion.d/ e.g. multiversion = provides:multiversion(1.9:rubygem-foo)' which would allow multiple versions of the foo gem to co-exist simultaneously for a 1.9 ruby install. So I have *still* not heard a convincing reason why we would ever need suffices in the Name: field. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 06.11.2012 12:54, Adam Spiers wrote:
However, in the few ugly cases where multi-version is required, it should be possible to accommodate - rubygemsdeps.rb could generate the following extra Provides:
multiversion(rubygem) multiversion(rubygem-foo) multiversion(rubygem-foo-1) multiversion(rubygem-foo-1_2) multiversion(1.9:rubygem-foo) multiversion(1.9:rubygem-foo-1) multiversion(1.9:rubygem-foo-1_2)
and then any product-oriented rpm could install the appropriate multiversion policy / policies into /etc/zypp/multiversion.d/ e.g.
multiversion = provides:multiversion(1.9:rubygem-foo)'
which would allow multiple versions of the foo gem to co-exist simultaneously for a 1.9 ruby install.
So I have *still* not heard a convincing reason why we would ever need suffices in the Name: field.
OK, let me give you one: to avoid all the mess you just listed. 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) wrote:
On 06.11.2012 12:54, Adam Spiers wrote:
However, in the few ugly cases where multi-version is required, it should be possible to accommodate - rubygemsdeps.rb could generate the following extra Provides:
multiversion(rubygem) multiversion(rubygem-foo) multiversion(rubygem-foo-1) multiversion(rubygem-foo-1_2) multiversion(1.9:rubygem-foo) multiversion(1.9:rubygem-foo-1) multiversion(1.9:rubygem-foo-1_2)
and then any product-oriented rpm could install the appropriate multiversion policy / policies into /etc/zypp/multiversion.d/ e.g.
multiversion = provides:multiversion(1.9:rubygem-foo)'
which would allow multiple versions of the foo gem to co-exist simultaneously for a 1.9 ruby install.
So I have *still* not heard a convincing reason why we would ever need suffices in the Name: field.
OK, let me give you one: to avoid all the mess you just listed.
It's not any more messy than the automatic Provides: which rubygemsdeps.rb already generates, and has a number of advantages over -1_0 suffixing: - automatically generated so no manual renaming required by packager - doesn't pollute the Name: field with version info already in the Version: field - eliminates confusion in the packaging policy about when to use suffixing and when not to use it - hidden from the user (e.g. 'rpm -q rubygem-foo' always gives the user the answer they intuitively expect) - allows multiple minor versions to co-exist on the same machine, just like bundler does - allows *optional* enabling/disabling of multiversion: - for all gems system-wide - per gem - per gem major version - per gem minor version - per Ruby version and gem - per Ruby version and gem major version - per Ruby version and gem minor version -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Adam Spiers <aspiers@suse.com> [Nov 06. 2012 14:32]:
It's not any more messy than the automatic Provides: which rubygemsdeps.rb already generates, and has a number of advantages over -1_0 suffixing:
- automatically generated so no manual renaming required by packager
- doesn't pollute the Name: field with version info already in the Version: field
- eliminates confusion in the packaging policy about when to use suffixing and when not to use it
- hidden from the user (e.g. 'rpm -q rubygem-foo' always gives the user the answer they intuitively expect)
- allows multiple minor versions to co-exist on the same machine, just like bundler does
Actually, thats *exactly* how I would like RPM-packaged GEMs to behave.
- allows *optional* enabling/disabling of multiversion: - for all gems system-wide - per gem - per gem major version - per gem minor version - per Ruby version and gem - per Ruby version and gem major version - per Ruby version and gem minor version
The multiversion property is one of the main reasons I work with plain gems. I wouldn't want to disable it at all. 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
Klaus Kaempf (kkaempf@suse.de) wrote:
* Adam Spiers <aspiers@suse.com> [Nov 06. 2012 14:32]:
It's not any more messy than the automatic Provides: which rubygemsdeps.rb already generates, and has a number of advantages over -1_0 suffixing:
- automatically generated so no manual renaming required by packager
- doesn't pollute the Name: field with version info already in the Version: field
- eliminates confusion in the packaging policy about when to use suffixing and when not to use it
- hidden from the user (e.g. 'rpm -q rubygem-foo' always gives the user the answer they intuitively expect)
- allows multiple minor versions to co-exist on the same machine, just like bundler does
Actually, thats *exactly* how I would like RPM-packaged GEMs to behave.
- allows *optional* enabling/disabling of multiversion: - for all gems system-wide - per gem - per gem major version - per gem minor version - per Ruby version and gem - per Ruby version and gem major version - per Ruby version and gem minor version
The multiversion property is one of the main reasons I work with plain gems.
You mean plain as opposed to with a '-1_0' suffix?
I wouldn't want to disable it at all.
I can't think of a good reason either, but it sounds like some were aired in the workshop last week. I would really like to know some details about these objections to multiversioning of gem packages. The only difficulty I can think of is if both Ruby 1.8 and 1.9 were installed on the same system, and gem 'foo-1.2.3' was needed simultaneously for both installations. But this difficulty also exists within the suffixed naming scheme, so it's not a valid reason to reject the above non-suffixed proposal. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Adam Spiers <aspiers@suse.com> [Nov 12. 2012 14:46]:
The multiversion property is one of the main reasons I work with plain gems.
You mean plain as opposed to with a '-1_0' suffix?
I mean plain as in 'gem' as opposed to 'rpm'. 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
* Adam Spiers <aspiers@suse.com> [Nov 12. 2012 14:46]:
The only difficulty I can think of is if both Ruby 1.8 and 1.9 were installed on the same system, and gem 'foo-1.2.3' was needed simultaneously for both installations. But this difficulty also exists within the suffixed naming scheme, so it's not a valid reason to reject the above non-suffixed proposal.
Agreed. And zypper should be able to sort it out based on the dependencies. 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
Klaus Kaempf (kkaempf@suse.de) wrote:
* Adam Spiers <aspiers@suse.com> [Nov 12. 2012 14:46]:
The only difficulty I can think of is if both Ruby 1.8 and 1.9 were installed on the same system, and gem 'foo-1.2.3' was needed simultaneously for both installations. But this difficulty also exists within the suffixed naming scheme, so it's not a valid reason to reject the above non-suffixed proposal.
Agreed. And zypper should be able to sort it out based on the dependencies.
I'm not sure rpm allows multiple packages with the same (name, version, release, arch) tuple to be installed simultaneously. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Adam Spiers (aspiers@suse.com) wrote:
Stephan Kulow (coolo@suse.de) wrote:
On 06.11.2012 12:54, Adam Spiers wrote:
However, in the few ugly cases where multi-version is required, it should be possible to accommodate - rubygemsdeps.rb could generate the following extra Provides:
multiversion(rubygem) multiversion(rubygem-foo) multiversion(rubygem-foo-1) multiversion(rubygem-foo-1_2) multiversion(1.9:rubygem-foo) multiversion(1.9:rubygem-foo-1) multiversion(1.9:rubygem-foo-1_2)
and then any product-oriented rpm could install the appropriate multiversion policy / policies into /etc/zypp/multiversion.d/ e.g.
multiversion = provides:multiversion(1.9:rubygem-foo)'
which would allow multiple versions of the foo gem to co-exist simultaneously for a 1.9 ruby install.
So I have *still* not heard a convincing reason why we would ever need suffices in the Name: field.
OK, let me give you one: to avoid all the mess you just listed.
It's not any more messy than the automatic Provides: which rubygemsdeps.rb already generates, and has a number of advantages over -1_0 suffixing:
- automatically generated so no manual renaming required by packager
- doesn't pollute the Name: field with version info already in the Version: field
- eliminates confusion in the packaging policy about when to use suffixing and when not to use it
- hidden from the user (e.g. 'rpm -q rubygem-foo' always gives the user the answer they intuitively expect)
- allows multiple minor versions to co-exist on the same machine, just like bundler does
- allows *optional* enabling/disabling of multiversion: - for all gems system-wide - per gem - per gem major version - per gem minor version - per Ruby version and gem - per Ruby version and gem major version - per Ruby version and gem minor version
I thought of more disadvantages to our current policy of suffixing for old versions only[1]: - When updating rubygem-foo from 1.2.x to 1.3.x, there is no reliable way to determine whether anything still depends on the old version (e.g. via a ~> 1.2.5 requirement). So it is impossible to know whether it is sufficient to simply upgrade rubygem-foo from 1.2.x to 1.3.x, or whether a new rubygem-foo-1_2 is also required. - Even if you do find something which depends on the old 1.2.x version, the addition of rubygem-foo-1_2 will not avoid breaking any projects which linkpac to rubygem-foo in (say) d:l:r:e rather than building against d:l:r:e via a <path> entry in the meta project config. - You have to decide how long the suffix needs to be (e.g. rubygem-foo-1 vs. rubygem-foo-1_2 vs. rubygem-foo-1_2_5) and that is effectively hardcoding unreliable assumptions about a) the versioning policy of that particular gem (since sadly not all gems adhere to semver.org) and b) the nature of the other packages' dependencies on foo. Unfortunately these last two disadvantages also apply to a scheme which never used suffices in the BS package name, as well as a scheme which *always* includes the suffix in the BS package name :-/ The fundamental problem here is that linkpac was never designed to express dependencies on a particular version of a package, i.e. it cannot express a version dependency like ">= 1.2" or "~> 1.2". One workaround for this particular problem is 'osc setlinkrev' but it's inherently problematic and also requires manual dependency resolution. Using <path> and building directly against d:l:r:e (say) would give automatic dependency resolution, but is not always appropriate. copypac is another option but is again manual. I should make an important distinction in this discussion: the question of when and how to suffix in the BS package name is different from the question of whether to suffix in the Name: field. AFAICS the multiversion scheme quoted above would allow us to drop suffices from the Name: field, but not from the BS package name. [1] http://en.opensuse.org/openSUSE:Packaging_Ruby#Updating_gem_packages_to_a_ne... -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Adam Spiers <aspiers@suse.com> [Nov 06. 2012 12:54]:
Stephan Kulow (coolo@suse.de) wrote:
On 06.11.2012 09:54, Klaus Kaempf wrote:
* Stephan Kulow <coolo@suse.de> [Nov 06. 2012 06:43]:
It's not a bug, it's a design limitation.
LOL
BTW: zypper doesn't like two packages named rubygem-foo either.
Can you please be more specific here ?
zypper is supporting multiple versions of a package (i.e. the linux kernel) for quite some time and I don't see issues with zypper and the four versions of sblim-sfcb in systemsmanagement:wbem either.
Yeah, if you configure multiversion for kernels in zypp.conf - do you want to change zypp.conf for all gems?
multiversion is not necessarily a requirement here. We are talking about a single OBS project providing the *choice* of multiple versions of a gem.
Right, thats the primary requirement. However, from a developer POV, the ability to install multiple versions of a single GEM is important when working with different Ruby/Rails projects.
AFAICS, sblim-sfcb in systemsmanagement:wbem is an example where multiversion would *not* be required, because e.g. 1.3.7 would only ever be installed on SP1 machines, and 1.3.11 on SP2 machines.
Not quite. I build sblim-sfcb in multiple versions so I can upgrade it on a e.g. SP1 machine without migrating it to SP2.
and then any product-oriented rpm could install the appropriate multiversion policy / policies into /etc/zypp/multiversion.d/
Shouldn't multiversion be the default for zypper ? Esp. since we put so much effort into shared library packaging with the ability to install multiple versions in parallel ? 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
Klaus Kaempf (kkaempf@suse.de) wrote:
* Adam Spiers <aspiers@suse.com> [Nov 06. 2012 12:54]:
Stephan Kulow (coolo@suse.de) wrote:
On 06.11.2012 09:54, Klaus Kaempf wrote:
* Stephan Kulow <coolo@suse.de> [Nov 06. 2012 06:43]:
It's not a bug, it's a design limitation.
LOL
BTW: zypper doesn't like two packages named rubygem-foo either.
Can you please be more specific here ?
zypper is supporting multiple versions of a package (i.e. the linux kernel) for quite some time and I don't see issues with zypper and the four versions of sblim-sfcb in systemsmanagement:wbem either.
Yeah, if you configure multiversion for kernels in zypp.conf - do you want to change zypp.conf for all gems?
multiversion is not necessarily a requirement here. We are talking about a single OBS project providing the *choice* of multiple versions of a gem.
Right, thats the primary requirement.
However, from a developer POV, the ability to install multiple versions of a single GEM is important when working with different Ruby/Rails projects.
Right. Potentially even multiple versions of the same minor version, e.g. 1.2.3 and 1.2.5. As I already mentioned[1], a '-1_2' Name suffix does not allow this (and has several other disadvantages).
AFAICS, sblim-sfcb in systemsmanagement:wbem is an example where multiversion would *not* be required, because e.g. 1.3.7 would only ever be installed on SP1 machines, and 1.3.11 on SP2 machines.
Not quite. I build sblim-sfcb in multiple versions so I can upgrade it on a e.g. SP1 machine without migrating it to SP2.
Ah, OK. Sounds like we agree about the need to support both use cases though.
and then any product-oriented rpm could install the appropriate multiversion policy / policies into /etc/zypp/multiversion.d/
Shouldn't multiversion be the default for zypper ?
Esp. since we put so much effort into shared library packaging with the ability to install multiple versions in parallel ?
Hah - I'm guessing there is a good reason it's not the default, but I have no idea what that is :) [1] http://lists.opensuse.org/opensuse-ruby/2012-11/msg00039.html -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 07.11.2012 12:39, Klaus Kaempf wrote:
and then any product-oriented rpm could install the appropriate multiversion policy / policies into /etc/zypp/multiversion.d/
Shouldn't multiversion be the default for zypper ?
Esp. since we put so much effort into shared library packaging with the ability to install multiple versions in parallel ?
So you want to rewrite the software stack *and* the build service to avoid what effort exactly? adding a suffix, right? 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> [Nov 07. 2012 13:07]:
On 07.11.2012 12:39, Klaus Kaempf wrote:
and then any product-oriented rpm could install the appropriate multiversion policy / policies into /etc/zypp/multiversion.d/
Shouldn't multiversion be the default for zypper ?
Esp. since we put so much effort into shared library packaging with the ability to install multiple versions in parallel ?
So you want to rewrite the software stack *and* the build service to avoid what effort exactly? adding a suffix, right?
Psst, you almost revealed my secret plan to rewrite RPM and disallow version suffixes alltogether. SCNR ! 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) wrote:
On 07.11.2012 12:39, Klaus Kaempf wrote:
and then any product-oriented rpm could install the appropriate multiversion policy / policies into /etc/zypp/multiversion.d/
Shouldn't multiversion be the default for zypper ?
Esp. since we put so much effort into shared library packaging with the ability to install multiple versions in parallel ?
So you want to rewrite the software stack *and* the build service to avoid what effort exactly?
Of course not, I'm not suggesting a rewrite and I seriously doubt Klaus is either. It's a valid question, and if the real answer is "no we can't make multiversion the default because $X" then please simply state what $X is.
adding a suffix, right?
No, the suffix debate is entirely independent of this question. -- 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> [Nov 06. 2012 10:13]:
On 06.11.2012 09:54, Klaus Kaempf wrote:
* Stephan Kulow <coolo@suse.de> [Nov 06. 2012 06:43]:
It's not a bug, it's a design limitation.
LOL
BTW: zypper doesn't like two packages named rubygem-foo either.
Can you please be more specific here ?
zypper is supporting multiple versions of a package (i.e. the linux kernel) for quite some time and I don't see issues with zypper and the four versions of sblim-sfcb in systemsmanagement:wbem either.
Yeah, if you configure multiversion for kernels in zypp.conf - do you want to change zypp.conf for all gems?
Ah, so thats the zypper issue you were referring to. Understood. I think that should be an easy problem to fix. 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> [Nov 05. 2012 20:13]:
https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp1&project=systemsmanagement%3Awbem https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp2&project=systemsmanagement%3Awbem
Well, what will happen if you buildrequire sblim-sfcb? I can tell you: the last built rpm will win -> not good
I cannot imagine that the BuildRequires solver will choose the _last built_ package. I'd expect it to choose the 'best' package (best architecture, best version)
, especially if it's important that the rpm has a specific version.
And that's exactly the point with building rubygems. You _need_ to specify exact versions of your build dependencies. -> Problem solved 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
* Adam Spiers <aspiers@suse.com> [Nov 05. 2012 19:54]:
Klaus Kaempf (kkaempf@suse.de) wrote:
* Stephan Kulow <coolo@suse.de> [Nov 05. 2012 14:41]:
No, the suffix is only there to avoid clashes between two .rpm files. You can't have rubygem-<gem> twice in the build service.
Where can I file feature (bug ?) reports against the build service ? (SCNR!)
Then I'd advocate to keep the version suffix in the build service package name (to work around the above mentioned build service bug)
I don't understand what the bug is? It already seems to work fine in the example you cited:
https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp1&project=systemsmanagement%3Awbem https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp2&project=systemsmanagement%3Awbem ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The 'bug' is that I need to create two different 'package' entries in OBS. I'd rather see OBS support multiple versions for a package natively.
This should then allow us to have multiple versions of the same (ruby)gem in a build service project.
Example:
d:l:r:e/rubygem-foo-1_0 (-> builds rubygem-foo-1.0) foo-1.0.gem rubygem-foo.spec rubygem-foo.changes
d:l:r:e/rubygem-foo-1_1 (-> builds rubygem-foo-1.0)
I assume you meant rubygem-foo-1.1 there?
Yes, of course !
foo-1.1.gem rubygem-foo.spec rubygem-foo.changes
Note: the version suffix is only in the build service name, not in the .spec, .changes, or .rpm file.
Isn't that exactly what you did for sblim-sfcb above? Is there a particular reason why this wouldn't work for gem packages?
It will work. But as said before, you'll need to create two different (same rubygem-foo prefix, different suffix) packages in d:l:r:e 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
Klaus Kaempf (kkaempf@suse.de) wrote:
* Adam Spiers <aspiers@suse.com> [Nov 05. 2012 19:54]:
Klaus Kaempf (kkaempf@suse.de) wrote:
* Stephan Kulow <coolo@suse.de> [Nov 05. 2012 14:41]:
No, the suffix is only there to avoid clashes between two .rpm files. You can't have rubygem-<gem> twice in the build service.
Where can I file feature (bug ?) reports against the build service ? (SCNR!)
Then I'd advocate to keep the version suffix in the build service package name (to work around the above mentioned build service bug)
I don't understand what the bug is? It already seems to work fine in the example you cited:
https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp1&project=systemsmanagement%3Awbem https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp2&project=systemsmanagement%3Awbem ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The 'bug' is that I need to create two different 'package' entries in OBS. I'd rather see OBS support multiple versions for a package natively.
Presumably you mean a single package containing multiple spec files, rather than a single spec file containing multiple versions? The latter sounds like a disaster. But the former poses several challenges too, e.g. how would 'osc build' know which to build? And I can't really see any advantages to this - none of the files inside the project could be shared, so your current approach of using sblim-sfcb-$something to provide clean separation of sources / spec / changes / patches etc. seems to make the most sense to me. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Klaus Kaempf (kkaempf@suse.de) wrote:
* Adam Spiers <aspiers@suse.com> [Nov 05. 2012 19:54]:
Klaus Kaempf (kkaempf@suse.de) wrote:
* Stephan Kulow <coolo@suse.de> [Nov 05. 2012 14:41]:
No, the suffix is only there to avoid clashes between two .rpm files. You can't have rubygem-<gem> twice in the build service.
Where can I file feature (bug ?) reports against the build service ? (SCNR!)
Then I'd advocate to keep the version suffix in the build service package name (to work around the above mentioned build service bug)
I don't understand what the bug is? It already seems to work fine in the example you cited:
https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp1&project=systemsmanagement%3Awbem https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp2&project=systemsmanagement%3Awbem ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The 'bug' is that I need to create two different 'package' entries in OBS. I'd rather see OBS support multiple versions for a package natively.
Presumably you mean a single package containing multiple spec files, rather than a single spec file containing multiple versions? The latter sounds like a disaster. But the former poses several challenges too, e.g. how would 'osc build' know which to build? Please note that this is done quite often, e.g. to split out doc
On 11/06/2012 12:43 PM, Adam Spiers wrote: packages that would otherwise pollute the build log/time/requirements of the base package/spec. "osc build" AFAICS has magic to use the spec file that matches the OBS package name (if there is one), "osc vc" does not (yet) and needs you to explicitly mention the changes file you want to touch (you can do the same with osc build, though).
And I can't really see any advantages to this - none of the files inside the project could be shared, so your current approach of using sblim-sfcb-$something to provide clean separation of sources / spec / changes / patches etc. seems to make the most sense to me.
-- 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)
Sascha Peilicke (saschpe@suse.de) wrote:
On 11/06/2012 12:43 PM, Adam Spiers wrote:
Klaus Kaempf (kkaempf@suse.de) wrote:
The 'bug' is that I need to create two different 'package' entries in OBS. I'd rather see OBS support multiple versions for a package natively.
Presumably you mean a single package containing multiple spec files, rather than a single spec file containing multiple versions? The latter sounds like a disaster. But the former poses several challenges too, e.g. how would 'osc build' know which to build?
Please note that this is done quite often, e.g. to split out doc packages that would otherwise pollute the build log/time/requirements of the base package/spec.
Interesting to know, thanks! But in this case, the Name: field will have a different value, so it's not an identical scenario.
"osc build" AFAICS has magic to use the spec file that matches the OBS package name (if there is one),
I didn't know this either! Presumably this is the optional BUILD_DESCR argument to 'osc build' described in the osc man page? The man page says that it will be detected automatically but doesn't describe how in the section for 'osc build'. However in the section for 'osc buildinfo', it says The BUILD_DESCR argument is optional. BUILD_DESCR is a local RPM specfile or Debian "dsc" file. If specified, it is sent to the server, and the buildinfo will be based on it. If the argument is not supplied, the buildinfo is derived from the specfile which is currently on the source repository server.
"osc vc" does not (yet) and needs you to explicitly mention the changes file you want to touch (you can do the same with osc build, though).
OK, but that's just a usability issue rather than a blocker, right? But I still can't see any advantage to having a single OBS package which contains multiple .spec files for different versions of the same gem, and I can see many disadvantages. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Sascha Peilicke (saschpe@suse.de) wrote:
[...loveley Ruby fun...]
OK, but that's just a usability issue rather than a blocker, right? Totally off topic, but it's worth telling this story. First of all, "osc build" finds a default spec file because Dirk added that our of annoyance. "osc vc" doesn't find because it popen's a shell script originates from autobuild, has a copyright header from 2009, consists of 152 LOCS of which approximately 140 LOCS deal with input validation and finding changes files (which osc already knew). There you have the helpful message "Choose one of $BLA". But poor shell script can't know OBS packages because it's just a poor shell script from the "build"
On 11/06/2012 01:13 PM, Adam Spiers wrote: package. Did I forgot to tell that the Python code in osc that happens to popen said script also parses changes files (for even worse reasons)? Long story short, smart masterpieces like these are the result of brilliantly thought out design decisions by lone star software plumbers who may have even remotely heard of software design but decided to do it differently anyway. Of course this has the priceless advantage that plumbers can have an instant laugh watching the hole skyscraper of bullshit collapse once anyone tries to flip a single bit. Lastly, no real developer is interested in even caring for "usability", it's to close to the word hillbilly and would help only users. Getting back to the whole Ruby discussion, let's just do it! We can still make it more complicated once we managed to understand what we did to make it easier ;-) -- 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)
Sascha Peilicke (saschpe@suse.de) wrote:
Sascha Peilicke (saschpe@suse.de) wrote:
[...loveley Ruby fun...]
OK, but that's just a usability issue rather than a blocker, right? Totally off topic, but it's worth telling this story. First of all, "osc build" finds a default spec file because Dirk added that our of annoyance. "osc vc" doesn't find because it popen's a shell script originates from autobuild, has a copyright header from 2009, consists of 152 LOCS of which approximately 140 LOCS deal with input validation and finding changes files (which osc already knew). There you have the helpful message "Choose one of $BLA". But poor shell script can't know OBS packages because it's just a poor shell script from the "build"
On 11/06/2012 01:13 PM, Adam Spiers wrote: package. Did I forgot to tell that the Python code in osc that happens to popen said script also parses changes files (for even worse reasons)?
*lol* Ouch, that's horrible.
Long story short, smart masterpieces like these are the result of brilliantly thought out design decisions by lone star software plumbers who may have even remotely heard of software design but decided to do it differently anyway. Of course this has the priceless advantage that plumbers can have an instant laugh watching the hole skyscraper of bullshit collapse once anyone tries to flip a single bit.
Right - the problem here is lack of test suites. It's really crippling in these kinds of situations where major refactoring is badly needed but prevented from happening due to fear of breaking things.
Lastly, no real developer is interested in even caring for "usability", it's to close to the word hillbilly and would help only users.
FWIW, I care ;-)
Getting back to the whole Ruby discussion, let's just do it! We can still make it more complicated once we managed to understand what we did to make it easier ;-)
Hopefully you lot can reach a consensus tomorrow ;-) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Tue, 06 Nov 2012 16:26:56 +0100 Sascha Peilicke <saschpe@suse.de> wrote:
Sascha Peilicke (saschpe@suse.de) wrote:
[...loveley Ruby fun...]
OK, but that's just a usability issue rather than a blocker, right? Totally off topic, but it's worth telling this story. First of all, "osc build" finds a default spec file because Dirk added that our of annoyance. "osc vc" doesn't find because it popen's a shell script originates from autobuild, has a copyright header from 2009, consists of 152 LOCS of which approximately 140 LOCS deal with input validation and finding changes files (which osc already knew). There you have the helpful message "Choose one of $BLA". But poor shell
On 11/06/2012 01:13 PM, Adam Spiers wrote: script can't know OBS packages because it's just a poor shell script from the "build" package. Did I forgot to tell that the Python code in osc that happens to popen said script also parses changes files (for even worse reasons)?
Long story short, smart masterpieces like these are the result of brilliantly thought out design decisions by lone star software plumbers who may have even remotely heard of software design but decided to do it differently anyway. Of course this has the priceless advantage that plumbers can have an instant laugh watching the hole skyscraper of bullshit collapse once anyone tries to flip a single bit. Lastly, no real developer is interested in even caring for "usability", it's to close to the word hillbilly and would help only users.
OK, one my note to this off-topic, because I bring it back to gems and ruby. I plan to improve usability for request in build service to show also diffs in gem files same as we do for tarball ( nice feature ). But I found that there is no test suite in build service. And because setup own build service to verify that it works as I expect lead me to give up my attempt to improve code. I expect that build service have test cases that cover at least borders of API ( iterface between backend and frontend, cli tools etc. ). And one benefit of writing test case is that you have one more option to think about code and what it should do. Sometime it makes amazing results in simplifying code. Josef
Getting back to the whole Ruby discussion, let's just do it! We can still make it more complicated once we managed to understand what we did to make it easier ;-)
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 06.11.2012 16:37, Josef Reidinger wrote:
OK, one my note to this off-topic, because I bring it back to gems and ruby. I plan to improve usability for request in build service to show also diffs in gem files same as we do for tarball ( nice feature ). But I found that there is no test suite in build service. And because setup own build service to verify that it works as I expect lead me to give up my attempt to improve code. I expect that build service have test cases that cover at least borders of API ( iterface between backend and frontend, cli tools etc. ). And one benefit of writing test case is that you have one more option to think about code and what it should do. Sometime it makes amazing results in simplifying code.
What makes you think the build service has no test suite? It has no great test suite, but it has one. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Tue, 06 Nov 2012 17:04:06 +0100 Stephan Kulow <coolo@suse.de> wrote:
On 06.11.2012 16:37, Josef Reidinger wrote:
OK, one my note to this off-topic, because I bring it back to gems and ruby. I plan to improve usability for request in build service to show also diffs in gem files same as we do for tarball ( nice feature ). But I found that there is no test suite in build service. And because setup own build service to verify that it works as I expect lead me to give up my attempt to improve code. I expect that build service have test cases that cover at least borders of API ( iterface between backend and frontend, cli tools etc. ). And one benefit of writing test case is that you have one more option to think about code and what it should do. Sometime it makes amazing results in simplifying code.
What makes you think the build service has no test suite? It has no great test suite, but it has one.
Greetings, Stephan
If I look at https://github.com/openSUSE/open-build-service/tree/master I don't see anything how can I run it. I am interested in backend and there in src just some testData but I don't see way how to run it. If there is test suite it is not much intuitive placed. Josef -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 06.11.2012 17:10, Josef Reidinger wrote:
On Tue, 06 Nov 2012 17:04:06 +0100 Stephan Kulow <coolo@suse.de> wrote:
On 06.11.2012 16:37, Josef Reidinger wrote:
OK, one my note to this off-topic, because I bring it back to gems and ruby. I plan to improve usability for request in build service to show also diffs in gem files same as we do for tarball ( nice feature ). But I found that there is no test suite in build service. And because setup own build service to verify that it works as I expect lead me to give up my attempt to improve code. I expect that build service have test cases that cover at least borders of API ( iterface between backend and frontend, cli tools etc. ). And one benefit of writing test case is that you have one more option to think about code and what it should do. Sometime it makes amazing results in simplifying code.
What makes you think the build service has no test suite? It has no great test suite, but it has one.
Greetings, Stephan
If I look at https://github.com/openSUSE/open-build-service/tree/master I don't see anything how can I run it. I am interested in backend and there in src just some testData but I don't see way how to run it. If there is test suite it is not much intuitive placed.
Where I grew up we bounced into the IRC channel of the project and asked "how do you run your test suite?" instead of writing lengthy mails to unrelated mailing lists. But be it as it is: The backend has indeed no test suite on its own, but we try to test the most important stuff from the API test suite as tests are much nicer in ruby. So your target would be https://github.com/openSUSE/open-build-service/blob/master/src/api/test/func... Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Am 06.11.2012 17:04, schrieb Stephan Kulow:
On 06.11.2012 16:37, Josef Reidinger wrote:
OK, one my note to this off-topic, because I bring it back to gems and ruby. I plan to improve usability for request in build service to show also diffs in gem files same as we do for tarball ( nice feature ). But I found that there is no test suite in build service. And because setup own build service to verify that it works as I expect lead me to give up my attempt to improve code. I expect that build service have test cases that cover at least borders of API ( iterface between backend and frontend, cli tools etc. ). And one benefit of writing test case is that you have one more option to think about code and what it should do. Sometime it makes amazing results in simplifying code.
What makes you think the build service has no test suite? It has no great test suite, but it has one. It should be added that it actually has several, you can watch them run at http://ci.opensuse.org/ -- 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 (saschpe@suse.de) wrote:
Am 06.11.2012 17:04, schrieb Stephan Kulow:
On 06.11.2012 16:37, Josef Reidinger wrote:
OK, one my note to this off-topic, because I bring it back to gems and ruby. I plan to improve usability for request in build service to show also diffs in gem files same as we do for tarball ( nice feature ). But I found that there is no test suite in build service. And because setup own build service to verify that it works as I expect lead me to give up my attempt to improve code. I expect that build service have test cases that cover at least borders of API ( iterface between backend and frontend, cli tools etc. ). And one benefit of writing test case is that you have one more option to think about code and what it should do. Sometime it makes amazing results in simplifying code.
What makes you think the build service has no test suite? It has no great test suite, but it has one.
It should be added that it actually has several, you can watch them run at http://ci.opensuse.org/
http://en.opensuse.org/Build_Service links to this and other useful things from its 'Source code and testing' section. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Adam Spiers <aspiers@suse.com> [Nov 06. 2012 12:43]:
Klaus Kaempf (kkaempf@suse.de) wrote:
* Adam Spiers <aspiers@suse.com> [Nov 05. 2012 19:54]:
Klaus Kaempf (kkaempf@suse.de) wrote:
* Stephan Kulow <coolo@suse.de> [Nov 05. 2012 14:41]:
No, the suffix is only there to avoid clashes between two .rpm files. You can't have rubygem-<gem> twice in the build service.
Where can I file feature (bug ?) reports against the build service ? (SCNR!)
Then I'd advocate to keep the version suffix in the build service package name (to work around the above mentioned build service bug)
I don't understand what the bug is? It already seems to work fine in the example you cited:
https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp1&project=systemsmanagement%3Awbem https://build.opensuse.org/package/view_file?file=sblim-sfcb.spec&package=sblim-sfcb-sle11-sp2&project=systemsmanagement%3Awbem ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The 'bug' is that I need to create two different 'package' entries in OBS. I'd rather see OBS support multiple versions for a package natively.
Presumably you mean a single package containing multiple spec files, rather than a single spec file containing multiple versions?
Yes. I'm looking for native support for 'multiversion' in OBS. Something like branches/tags in a source code control system.
The latter sounds like a disaster.
Oh, absolutely. Adding a new version must not change any files of the older versions.
But the former poses several challenges too, e.g. how would 'osc build' know which to build?
If OBS supports multiversions, I'd expect 'osc build' to build the latest version by default and offer the ability to specify a version.
And I can't really see any advantages to this - none of the files inside the project could be shared, so your current approach of using sblim-sfcb-$something to provide clean separation of sources / spec / changes / patches etc. seems to make the most sense to me.
Sure, its working nicely. But it pollutes the namespace. Regards, 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
Klaus Kaempf (kkaempf@suse.de) wrote:
* Adam Spiers <aspiers@suse.com> [Nov 06. 2012 12:43]:
Klaus Kaempf (kkaempf@suse.de) wrote:
The 'bug' is that I need to create two different 'package' entries in OBS. I'd rather see OBS support multiple versions for a package natively.
Presumably you mean a single package containing multiple spec files, rather than a single spec file containing multiple versions?
Yes. I'm looking for native support for 'multiversion' in OBS. Something like branches/tags in a source code control system.
Ah, I'd be surprised it that happened any time soon - presumably it would require fundamental changes to the back-end.
And I can't really see any advantages to this - none of the files inside the project could be shared, so your current approach of using sblim-sfcb-$something to provide clean separation of sources / spec / changes / patches etc. seems to make the most sense to me.
Sure, its working nicely. But it pollutes the namespace.
There are two package namespaces, and it only pollutes one of them. I can't think of any significant disadvantages caused by the pollution though. If you can I'd be interested to hear about them. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Adam Spiers <aspiers@suse.com> [Nov 06. 2012 18:26]:
There are two package namespaces, and it only pollutes one of them. I can't think of any significant disadvantages caused by the pollution though. If you can I'd be interested to hear about them.
One is certainly loading time for - list of package in the project - monitor page - status page and all kinds of weird output from the search function. But namespace pollution is certainly secondary and should not prevent us from moving forward in having multiversion in d:l:r:e 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
Klaus Kaempf (kkaempf@suse.de) wrote:
* Adam Spiers <aspiers@suse.com> [Nov 06. 2012 18:26]:
There are two package namespaces, and it only pollutes one of them. I can't think of any significant disadvantages caused by the pollution though. If you can I'd be interested to hear about them.
One is certainly loading time for - list of package in the project - monitor page - status page
I suspect the differences could be measured in milliseconds not seconds ;-)
and all kinds of weird output from the search function.
Looks OK to me? $ osc se -s -V sblim-sfcb [snipped] systemsmanagement:wbem sblim-sfcb - 62 4649a7e12be11d30250a730f51eaea26 systemsmanagement:wbem sblim-sfcb-sle11-sp1 1.3.7 2 8dd9bf6f04502bf92227ba7d6cd4edb5 systemsmanagement:wbem sblim-sfcb-sle11-sp2 1.3.11 3 b145a639b5f113dce555015af4b3c7a5 systemsmanagement:wbem sblim-sfcb-unstable 1.4.2 15 ac34c8b360ee1a6894ce24f67c882fdc
But namespace pollution is certainly secondary and should not prevent us from moving forward in having multiversion in d:l:r:e
Right :) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Adam Spiers <aspiers@suse.com> [Nov 07. 2012 14:36]:
Looks OK to me?
$ osc se -s -V sblim-sfcb
[snipped]
systemsmanagement:wbem sblim-sfcb - 62 4649a7e12be11d30250a730f51eaea26 systemsmanagement:wbem sblim-sfcb-sle11-sp1 1.3.7 2 8dd9bf6f04502bf92227ba7d6cd4edb5 systemsmanagement:wbem sblim-sfcb-sle11-sp2 1.3.11 3 b145a639b5f113dce555015af4b3c7a5 systemsmanagement:wbem sblim-sfcb-unstable 1.4.2 15 ac34c8b360ee1a6894ce24f67c882fdc
But you can't see from there that all these 'packages' actually build the same rpm (in different versions) 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
Klaus Kaempf (kkaempf@suse.de) wrote:
* Adam Spiers <aspiers@suse.com> [Nov 07. 2012 14:36]:
Looks OK to me?
$ osc se -s -V sblim-sfcb
[snipped]
systemsmanagement:wbem sblim-sfcb - 62 4649a7e12be11d30250a730f51eaea26 systemsmanagement:wbem sblim-sfcb-sle11-sp1 1.3.7 2 8dd9bf6f04502bf92227ba7d6cd4edb5 systemsmanagement:wbem sblim-sfcb-sle11-sp2 1.3.11 3 b145a639b5f113dce555015af4b3c7a5 systemsmanagement:wbem sblim-sfcb-unstable 1.4.2 15 ac34c8b360ee1a6894ce24f67c882fdc
But you can't see from there that all these 'packages' actually build the same rpm (in different versions)
True :) I'm guessing that's just a UI issue that would be easy to fix. -- 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) wrote:
On 05.11.2012 14:31, Adam Spiers wrote:
It's not enough for this wiki page to document the current (latest) versioning schemes - the old versioning schemes existing in several repositories, and will continue to cause confusion for people like me unless we document a summary of the history behind the changes. I don't want other people to have to waste as much time on this as I have.
Hmm, isn't having the history next to the state confusing too?
Not if it's written clearly ;-) Also, if the policy is to rename gem_1_0 packages each time they're updated, then the history behind this is directly relevant to the status quo. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Am 05.11.2012 19:45, schrieb Adam Spiers:
Stephan Kulow (coolo@suse.de) wrote:
On 05.11.2012 14:31, Adam Spiers wrote:
It's not enough for this wiki page to document the current (latest) versioning schemes - the old versioning schemes existing in several repositories, and will continue to cause confusion for people like me unless we document a summary of the history behind the changes. I don't want other people to have to waste as much time on this as I have.
Hmm, isn't having the history next to the state confusing too?
Not if it's written clearly ;-)
Also, if the policy is to rename gem_1_0 packages each time they're updated, then the history behind this is directly relevant to the status quo.
Hmm, they are not renamed. You have rubygem-foo and you updated it from 1.0 to 2.0. And if you find that something still requires 1.0.*, you create a rubygem-foo-1_0 from the last rubygem-foo sources. If you find something requires 1.0.5, you create a rubygem-foo-1_0_5 and leave out the 1_0 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) wrote:
Am 05.11.2012 19:45, schrieb Adam Spiers:
Stephan Kulow (coolo@suse.de) wrote:
On 05.11.2012 14:31, Adam Spiers wrote:
It's not enough for this wiki page to document the current (latest) versioning schemes - the old versioning schemes existing in several repositories, and will continue to cause confusion for people like me unless we document a summary of the history behind the changes. I don't want other people to have to waste as much time on this as I have.
Hmm, isn't having the history next to the state confusing too?
Not if it's written clearly ;-)
Also, if the policy is to rename gem_1_0 packages each time they're updated, then the history behind this is directly relevant to the status quo.
Hmm, they are not renamed.
I think we are both getting confused by each other's vague wording ;-) You said:
We didn't rename all gem_1_0 packages yet, but we're going there whenever we update a package.
That's the renaming I was referring to. Maybe I misled you by using the words 'each time'. Please can you explain exactly what you mean by the above sentence?
You have rubygem-foo and you updated it from 1.0 to 2.0. And if you find that something still requires 1.0.*, you create a rubygem-foo-1_0 from the last rubygem-foo sources.
Yes, I understood that, although I still don't see a good reason for it[1].
If you find something requires 1.0.5, you create a rubygem-foo-1_0_5 and leave out the 1_0
I don't understand this - is there a typo? What does "leave out the 1_0" mean? Thanks, Adam [1] http://lists.opensuse.org/opensuse-ruby/2012-11/msg00035.html -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
[disclaimer: I am still new to all this so there may be stupid things in this email ;-) ] Stephan Kulow (coolo@suse.de) wrote:
Am 25.10.2012 16:42, schrieb Adam Spiers:
No, these are limitations in rpm itself. As darix pointed out last year, bundler's ~> operator cannot map straightforwardly into rpm Requires expressions:
http://lists.opensuse.org/opensuse-ruby/2011-07/msg00000.html
Yeah, but that information is outdated - if you read the thread a year later: http://lists.opensuse.org/opensuse-ruby/2012-07/msg00025.html
Yeah, I read that too, but I'm a bit confused now, because that post says "But this strange suffixing is no longer necessary anyway", which seems to conflict with what you are now saying:
So the policy we live is this: we package <gem> as rubygem-<gem> and only add a version suffix only if something requires an old version of <gem> (and then only to the old version) or if <gem> is <rails> - for historical reasons :)
So I must be misunderstanding something. If something requires an old version, why not just require rubygem-foo-1_0? Since like you said in that post, the automatic provides for the foo 1.0 gem would make that virtual package available:
The automatic provides cover the old names, but I kind of hope we can drop them in the future:
rubygem(1.9.1:rails) = 3.2.7 rubygem(rails) = 3.2.7 rubygem-rails = 3.2.7 rubygem-rails-3 = 3.2.7 rubygem-rails-3_2 = 3.2.7 rubygem-rails-3_2_7 = 3.2.7
These also seem to solve the ~> problem, since foo ~> 1.2.3 translates to Requires: rubygem-foo-1.2 >= 1.2.3 but that suggests that the automatic provides should not be dropped.
We didn't rename all gem_1_0 packages yet, but we're going there whenever we update a package.
I see. It would be extremely helpful to document this procedure here: http://en.opensuse.org/openSUSE:Packaging_Ruby I guess it's mainly a question of changing the Name: field and then running gem2rpm *.gem -o *.spec or am I way off? Thanks, Adam -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 30.10.2012 17:36, Adam Spiers wrote:
So I must be misunderstanding something. If something requires an old version, why not just require rubygem-foo-1_0? Since like you said in that post, the automatic provides for the foo 1.0 gem would make that virtual package available:
You don't need to require anything - the requires and provides are all done automatically and that's not the reason for the suffix.
We didn't rename all gem_1_0 packages yet, but we're going there whenever we update a package.
I see. It would be extremely helpful to document this procedure here:
http://en.opensuse.org/openSUSE:Packaging_Ruby
I guess it's mainly a question of changing the Name: field and then running
gem2rpm *.gem -o *.spec
or am I way off?
Basically, but for factory inclusion you also need to make the spec file and the .changes file named according to Name. 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) wrote:
On 30.10.2012 17:36, Adam Spiers wrote:
So I must be misunderstanding something. If something requires an old version, why not just require rubygem-foo-1_0? Since like you said in that post, the automatic provides for the foo 1.0 gem would make that virtual package available:
You don't need to require anything - the requires and provides are all done automatically
Yes I know, I was talking about how the automatic process works :-) If gem 'foo' has a dependency 'bar ~> 1.2.3' then what do the automatic requires for 'foo' look like? Presumably like this, right? rubygem-bar-1_2 >= 1.2.3
and that's not the reason for the suffix.
So what *is* / was the reason for the suffix?
We didn't rename all gem_1_0 packages yet, but we're going there whenever we update a package.
I see. It would be extremely helpful to document this procedure here:
http://en.opensuse.org/openSUSE:Packaging_Ruby
I guess it's mainly a question of changing the Name: field and then running
gem2rpm *.gem -o *.spec
or am I way off?
Basically, but for factory inclusion you also need to make the spec file and the .changes file named according to Name.
OK, thanks. But again this needs to be documented. I could update that wiki page but I'm not 100% confident I'd get it right. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Adam Spiers (aspiers@suse.com) wrote:
Stephan Kulow (coolo@suse.de) wrote:
The automatic provides cover the old names, but I kind of hope we can drop them in the future:
rubygem(1.9.1:rails) = 3.2.7 rubygem(rails) = 3.2.7 rubygem-rails = 3.2.7 rubygem-rails-3 = 3.2.7 rubygem-rails-3_2 = 3.2.7 rubygem-rails-3_2_7 = 3.2.7
These also seem to solve the ~> problem, since
foo ~> 1.2.3
translates to
Requires: rubygem-foo-1.2 >= 1.2.3
but that suggests that the automatic provides should not be dropped.
Whoops, that should have read Requires: rubygem-foo-1_2 >= 1.2.3 -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
* Adam Spiers <aspiers@suse.com> [Oct 25. 2012 16:42]:
Another thing to bear in mind is that even though this is an openSUSE list, the reality is that rpm packaging of gems will in some contexts be done by SUSE employees and driven by the need for those rpms as part of the platform for a current or future SUSE product such as a release of SUSE Studio or Cloud. In that context, there *may* be more compelling reasons to have one rpm per gem than there would normally be, e.g. to conform with existing product maintenance mechanisms (security updates are the most obvious, but IIRC there are automated per-rpm licensing checks too and maybe other legalities which would probably be circumvented by shipping bundles instead). So the question is whether the additional effort in packaging is justified or not.
Well, I agree with the requirements (maintainable software) but not with the implementation (forcing everything through the RPM needle eye). How about extending zypper to cope with GEMs as well as RPMs ? 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 10/25/2012 06:10 PM, Klaus Kaempf wrote:
* Adam Spiers<aspiers@suse.com> [Oct 25. 2012 16:42]:
Another thing to bear in mind is that even though this is an openSUSE list, the reality is that rpm packaging of gems will in some contexts be done by SUSE employees and driven by the need for those rpms as part of the platform for a current or future SUSE product such as a release of SUSE Studio or Cloud. In that context, there *may* be more compelling reasons to have one rpm per gem than there would normally be, e.g. to conform with existing product maintenance mechanisms (security updates are the most obvious, but IIRC there are automated per-rpm licensing checks too and maybe other legalities which would probably be circumvented by shipping bundles instead). So the question is whether the additional effort in packaging is justified or not. Well, I agree with the requirements (maintainable software) but not with the implementation (forcing everything through the RPM needle eye).
How about extending zypper to cope with GEMs as well as RPMs ?
Duncan tried that during hackweek, but ran into some problems. It might still be a valid approach though. James T. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Hi Adam, On 10/24/2012 08:24 PM, Adam Spiers wrote:
Maybe I'll try again with systemsmanagement:chef.
Nanuk and I (okay only Nanuk these days) are trying to get systemsmanagement:chef working, so we should really work together on that. We are moving from Puppet to Chef for managing susestudo.com, so we want the packages there to be stable for SLE11 SP2. If it's too much work though we might resort to sticking with gems and laying things on top for Studio Online. But regardless I would like to help the openSUSE community as much as we can with the packaging of Chef (and Puppet). Cheers, James T. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
James Tan (jatan@suse.de) wrote:
Hi Adam,
On 10/24/2012 08:24 PM, Adam Spiers wrote:
Maybe I'll try again with systemsmanagement:chef.
Nanuk and I (okay only Nanuk these days) are trying to get systemsmanagement:chef working, so we should really work together on that.
Agreed!
We are moving from Puppet to Chef for managing susestudo.com, so we want the packages there to be stable for SLE11 SP2. If it's too much work though we might resort to sticking with gems and laying things on top for Studio Online. But regardless I would like to help the openSUSE community as much as we can with the packaging of Chef (and Puppet).
OK great, so would I - it sounds like our interests are strongly aligned! I'll try to base systemsmanagement:crowbar on systemsmanagement:chef from now on, and will ping you if I run into trouble. -- 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) wrote:
Hi,
Want to know what I did for #hackweek8? I pulled ruby packaging apart and put it back together.
[snipped]
As gem packaging has to be 99% automatic to compete with out of rpm gem, I went for calling gem install with -f and ignore buildignores.
To have a way to check dependencies in OBS, I created a small package called "all-good", that itself buildrequires all gems in the repository. That means for a rails update you will only need one ring: update all gems and then let the scheduler calculate if all-good can be expanded or if something misses dependencies. (all-good has a script to update the buildrequires if you had new gems)
I just updated that script (update-source.sh) so that it can be used in other projects too: https://build.opensuse.org/request/show/142153 However I noticed it also automatically generates BuildRequires: for non-rubygem packages. Presumably this is unintentional? If so I'll fix it. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
participants (7)
-
Adam Spiers -
James Tan -
Jordi Massaguer Pla -
Josef Reidinger -
Klaus Kaempf -
Sascha Peilicke -
Stephan Kulow