[opensuse-ruby] non-rubyabi-specific gem version dependencies
rubygemsdeps.rb as provided by ruby-common-1.0 in d:l:r automatically generates Provides: headers which, with one exception, contain the rubyabi version: # version without ruby version - asking for trouble puts "rubygem(#{spec.name}) = #{spec.version}" if rubyabi puts "rubygem(#{rubyabi}:#{spec.name}) = #{spec.version}" puts "rubygem(#{rubyabi}:#{spec.name}:#{versions[0]}) = #{spec.version}" if versions.length > 1 puts "rubygem(#{rubyabi}:#{spec.name}:#{versions[0]}.#{versions[1]}) = #{spec.version}" if versions.length > 2 puts "rubygem(#{rubyabi}:#{spec.name}:#{versions[0]}.#{versions[1]}.#{versions[2]}) = #{spec.version}" if versions.length > 3 end For example: rubygem(oa-openid) = 0.3.2 rubygem(1.9.1:oa-openid) = 0.3.2 rubygem(1.9.1:oa-openid:0) = 0.3.2 rubygem(1.9.1:oa-openid:0.3) = 0.3.2 However I have just encountered a situation where I think it would make sense if it also Provided: rubygem(oa-openid) = 0.3.2 rubygem(oa-openid:0) = 0.3.2 rubygem(oa-openid:0.3) = 0.3.2 The "asking for trouble" comment above cryptically suggests that this is a bad idea, but I would like to know why. The situation I have is as follows: - d:l:r:e provides both rubygem-erubis-2_6 and rubygem-erubis-2_7 - systemsmanagement:chef/rubygem-chef requires erubis >= 0 - systemsmanagement:chef/rubygem-chef which requires rubygem-chef is in 'unresolvable' state because the Build Service doesn't know how to choose between the two erubis versions. The clean solution would be to add a hint to rubygem-chef.spec: Requires: rubygem(%{rb_ver}:erubis:2.7) but 'osc build' gets confused by %{rb_ver}. I don't want to manually specify the Ruby version in the .spec file, because there is no specific dependency on Ruby 1.9 and I want the .spec file to build against 1.8 too (e.g. if we linkpac to another project which builds against Ruby 1.8 on SLES11). Another possibility for the hint is Requires: rubygem-erubis >= 2.7 but it would be better if it was possible to use the pessimistic ~> version since that is less likely to break in the future: Requires: rubygem(erubis:2.7) So can someone please explain why having extra automatic Provides: which omit the rubyabi would be asking for trouble? Thanks! Adam -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Wed, 21 Nov 2012 16:21:35 +0000 Adam Spiers <aspiers@suse.com> wrote:
rubygemsdeps.rb as provided by ruby-common-1.0 in d:l:r automatically generates Provides: headers which, with one exception, contain the rubyabi version:
# version without ruby version - asking for trouble puts "rubygem(#{spec.name}) = #{spec.version}" if rubyabi puts "rubygem(#{rubyabi}:#{spec.name}) = #{spec.version}" puts "rubygem(#{rubyabi}:#{spec.name}:#{versions[0]}) = #{spec.version}" if versions.length > 1 puts "rubygem(#{rubyabi}:#{spec.name}:#{versions[0]}.#{versions[1]}) = #{spec.version}" if versions.length > 2 puts "rubygem(#{rubyabi}:#{spec.name}:#{versions[0]}.#{versions[1]}.#{versions[2]}) = #{spec.version}" if versions.length > 3 end
For example:
rubygem(oa-openid) = 0.3.2 rubygem(1.9.1:oa-openid) = 0.3.2 rubygem(1.9.1:oa-openid:0) = 0.3.2 rubygem(1.9.1:oa-openid:0.3) = 0.3.2
However I have just encountered a situation where I think it would make sense if it also Provided:
rubygem(oa-openid) = 0.3.2 rubygem(oa-openid:0) = 0.3.2 rubygem(oa-openid:0.3) = 0.3.2
The "asking for trouble" comment above cryptically suggests that this is a bad idea, but I would like to know why.
The situation I have is as follows:
- d:l:r:e provides both rubygem-erubis-2_6 and rubygem-erubis-2_7
- systemsmanagement:chef/rubygem-chef requires erubis >= 0
- systemsmanagement:chef/rubygem-chef which requires rubygem-chef is in 'unresolvable' state because the Build Service doesn't know how to choose between the two erubis versions.
The clean solution would be to add a hint to rubygem-chef.spec:
Requires: rubygem(%{rb_ver}:erubis:2.7)
but 'osc build' gets confused by %{rb_ver}. I don't want to manually specify the Ruby version in the .spec file, because there is no specific dependency on Ruby 1.9 and I want the .spec file to build against 1.8 too (e.g. if we linkpac to another project which builds against Ruby 1.8 on SLES11).
Another possibility for the hint is
Requires: rubygem-erubis >= 2.7
but it would be better if it was possible to use the pessimistic ~> version since that is less likely to break in the future:
Requires: rubygem(erubis:2.7)
So can someone please explain why having extra automatic Provides: which omit the rubyabi would be asking for trouble?
Because you cannot mix gems from 1.8 and 1.9. So if you have one OBS that builds againts 1.8 and another repo that builds againsts 1.9, then there is potential problem ,that solver can choose mixture of gems, that won't work. BTW we are solving this issue also in OBS and we use in project config prefer keyword - http://en.opensuse.org/openSUSE:Build_Service_prjconf#Prefer eg we have Prefer: rubygem-activesupport-3_2 Prefer: rubygem-activeresource-3_2 Prefer: rubygem-activerecord-3_2 Prefer: rubygem-railties-3_2 For gems that doesn't require specific version of rails or have less strict requirement. ( I know that Rudi doesn't like it much, because it means, all products in one project must respect it, or in whole distro, so he prefer to solve it in package then in project config ) Josef
Thanks! Adam
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Josef Reidinger (jreidinger@suse.cz) wrote:
On Wed, 21 Nov 2012 16:21:35 +0000 Adam Spiers <aspiers@suse.com> wrote:
rubygemsdeps.rb as provided by ruby-common-1.0 in d:l:r automatically generates Provides: headers which, with one exception, contain the rubyabi version:
# version without ruby version - asking for trouble puts "rubygem(#{spec.name}) = #{spec.version}"
[snipped]
For example:
rubygem(oa-openid) = 0.3.2 rubygem(1.9.1:oa-openid) = 0.3.2 rubygem(1.9.1:oa-openid:0) = 0.3.2 rubygem(1.9.1:oa-openid:0.3) = 0.3.2
However I have just encountered a situation where I think it would make sense if it also Provided:
rubygem(oa-openid) = 0.3.2 rubygem(oa-openid:0) = 0.3.2 rubygem(oa-openid:0.3) = 0.3.2
The "asking for trouble" comment above cryptically suggests that this is a bad idea, but I would like to know why.
[snipped]
So can someone please explain why having extra automatic Provides: which omit the rubyabi would be asking for trouble?
Because you cannot mix gems from 1.8 and 1.9. So if you have one OBS that builds againts 1.8 and another repo that builds againsts 1.9, then there is potential problem ,that solver can choose mixture of gems, that won't work.
I don't understand that at all. I'm suggesting adding extra Provides: symbols to gem A so that gem B can have extra Requires: on one of those symbols. That is *less* permissive than the current situation, not more permissive, so it can't introduce any new scenario to the solver (e.g. ones which mix 1.8 and 1.9 gems). It can only *reduce* the number of possibilities the solver has to look at. And like I said, I can already *almost* accomplish what I want via Requires: rubygem-erubis >= 2.7 which is not specific to a particular Ruby ABI. How would allowing Requires: rubygem(erubis:2.7) create any new problems which don't already exist?
BTW we are solving this issue also in OBS and we use in project config prefer keyword - http://en.opensuse.org/openSUSE:Build_Service_prjconf#Prefer eg we have Prefer: rubygem-activesupport-3_2 Prefer: rubygem-activeresource-3_2 Prefer: rubygem-activerecord-3_2 Prefer: rubygem-railties-3_2
OK, great! But that depends on the version-suffixed Provides: symbols which coolo already stated he hopes can be dropped in the future: http://lists.opensuse.org/opensuse-ruby/2012-07/msg00025.html So it is actually a good argument in favour of my suggestion of adding automatic Provides: rubygem($GEM:$VERSION) symbols to rubygemsdeps.rb.
( I know that Rudi doesn't like it much, because it means, all products in one project must respect it, or in whole distro, so he prefer to solve it in package then in project config )
Is there currently a way to do it per package? Thanks! Adam -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Wed, 21 Nov 2012 17:00:40 +0000 Adam Spiers <aspiers@suse.com> wrote:
Josef Reidinger (jreidinger@suse.cz) wrote:
On Wed, 21 Nov 2012 16:21:35 +0000 Adam Spiers <aspiers@suse.com> wrote:
rubygemsdeps.rb as provided by ruby-common-1.0 in d:l:r automatically generates Provides: headers which, with one exception, contain the rubyabi version:
# version without ruby version - asking for trouble puts "rubygem(#{spec.name}) = #{spec.version}"
[snipped]
For example:
rubygem(oa-openid) = 0.3.2 rubygem(1.9.1:oa-openid) = 0.3.2 rubygem(1.9.1:oa-openid:0) = 0.3.2 rubygem(1.9.1:oa-openid:0.3) = 0.3.2
However I have just encountered a situation where I think it would make sense if it also Provided:
rubygem(oa-openid) = 0.3.2 rubygem(oa-openid:0) = 0.3.2 rubygem(oa-openid:0.3) = 0.3.2
The "asking for trouble" comment above cryptically suggests that this is a bad idea, but I would like to know why.
[snipped]
So can someone please explain why having extra automatic Provides: which omit the rubyabi would be asking for trouble?
Because you cannot mix gems from 1.8 and 1.9. So if you have one OBS that builds againts 1.8 and another repo that builds againsts 1.9, then there is potential problem ,that solver can choose mixture of gems, that won't work.
I don't understand that at all. I'm suggesting adding extra Provides: symbols to gem A so that gem B can have extra Requires: on one of those symbols. That is *less* permissive than the current situation, not more permissive, so it can't introduce any new scenario to the solver (e.g. ones which mix 1.8 and 1.9 gems). It can only *reduce* the number of possibilities the solver has to look at.
And like I said, I can already *almost* accomplish what I want via
Requires: rubygem-erubis >= 2.7
which is not specific to a particular Ruby ABI. How would allowing
Requires: rubygem(erubis:2.7)
create any new problems which don't already exist?
It creates problem, because you build your gem with ruby 1.8 or 1.9 and what you want to achieve is ensure that rubygem(erubis:2.7) is also built for same ABI. Without ABI version you risk install of gems for different ABIs.
BTW we are solving this issue also in OBS and we use in project config prefer keyword - http://en.opensuse.org/openSUSE:Build_Service_prjconf#Prefer eg we have Prefer: rubygem-activesupport-3_2 Prefer: rubygem-activeresource-3_2 Prefer: rubygem-activerecord-3_2 Prefer: rubygem-railties-3_2
OK, great! But that depends on the version-suffixed Provides: symbols which coolo already stated he hopes can be dropped in the future:
http://lists.opensuse.org/opensuse-ruby/2012-07/msg00025.html
Yes, but when it exists then it creates multichoice. So when it disappear, then you should not specify which version you need and only dependency in gem should be enough.
So it is actually a good argument in favour of my suggestion of adding automatic Provides: rubygem($GEM:$VERSION) symbols to rubygemsdeps.rb.
( I know that Rudi doesn't like it much, because it means, all products in one project must respect it, or in whole distro, so he prefer to solve it in package then in project config )
Is there currently a way to do it per package?
I think not for multichoice and I think that it is something that maybe should be solved by build service to automatic make well defined choice when you don't care what package or version is used. Josef
Thanks! Adam
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Josef Reidinger (jreidinger@suse.cz) wrote:
Adam Spiers <aspiers@suse.com> wrote:
Josef Reidinger (jreidinger@suse.cz) wrote:
Adam Spiers <aspiers@suse.com> wrote:
[snipped]
So can someone please explain why having extra automatic Provides: which omit the rubyabi would be asking for trouble?
Because you cannot mix gems from 1.8 and 1.9. So if you have one OBS that builds againts 1.8 and another repo that builds againsts 1.9, then there is potential problem ,that solver can choose mixture of gems, that won't work.
I don't understand that at all. I'm suggesting adding extra Provides: symbols to gem A so that gem B can have extra Requires: on one of those symbols. That is *less* permissive than the current situation, not more permissive, so it can't introduce any new scenario to the solver (e.g. ones which mix 1.8 and 1.9 gems). It can only *reduce* the number of possibilities the solver has to look at.
[snipped]
It creates problem, because you build your gem with ruby 1.8 or 1.9 and what you want to achieve is ensure that rubygem(erubis:2.7) is also built for same ABI. Without ABI version you risk install of gems for different ABIs.
Why do you say "without ABI version" ? I am not suggesting dropping the existing Requires which has the ABI version dependency. Maybe you are missing the fact that rubygem-chef will still have this automatic dependency: Requires: rubygem(1.9:erubis) >= 0 as seen here: https://build.opensuse.org/package/binary?arch=x86_64&filename=rubygem-chef-10.16.2-7.1.x86_64.rpm&package=rubygem-chef&project=systemsmanagement%3Achef&repository=openSUSE_12.2 When this is combined with the *additional* manual dependency which I am suggesting, i.e. Requires: rubygem(erubis:2.7) then the combination ensures there is no risk of getting the wrong ABI or the Build Service not knowing which version to choose.
BTW we are solving this issue also in OBS and we use in project config prefer keyword - http://en.opensuse.org/openSUSE:Build_Service_prjconf#Prefer eg we have Prefer: rubygem-activesupport-3_2 Prefer: rubygem-activeresource-3_2 Prefer: rubygem-activerecord-3_2 Prefer: rubygem-railties-3_2
OK, great! But that depends on the version-suffixed Provides: symbols which coolo already stated he hopes can be dropped in the future:
http://lists.opensuse.org/opensuse-ruby/2012-07/msg00025.html
Yes, but when it exists then it creates multichoice.
You mean multiple choices of ABIs for the solver, or multiple choices of syntax in prjconf? This is not true for the former. For the latter, although it is true, that is the universal approach to improving API design: a) introduce a new mechanism which deprecates the old one, b) retire usage of the old, and finally c) drop support for the old. So I don't see anything wrong with it.
So when it disappear, then you should not specify which version you need and only dependency in gem should be enough.
When what disappears? Sorry, I don't understand what you meant here.
I think not for multichoice and I think that it is something that maybe should be solved by build service to automatic make well defined choice when you don't care what package or version is used.
They could have easily made it just choose the newest version. The fact that they didn't suggests to me that there was a good reason for the BS not to make the choice by itself. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Thu, 22 Nov 2012 13:38:29 +0000 Adam Spiers <aspiers@suse.com> wrote:
Josef Reidinger (jreidinger@suse.cz) wrote:
Adam Spiers <aspiers@suse.com> wrote:
Josef Reidinger (jreidinger@suse.cz) wrote:
Adam Spiers <aspiers@suse.com> wrote:
[snipped]
So can someone please explain why having extra automatic Provides: which omit the rubyabi would be asking for trouble?
Because you cannot mix gems from 1.8 and 1.9. So if you have one OBS that builds againts 1.8 and another repo that builds againsts 1.9, then there is potential problem ,that solver can choose mixture of gems, that won't work.
I don't understand that at all. I'm suggesting adding extra Provides: symbols to gem A so that gem B can have extra Requires: on one of those symbols. That is *less* permissive than the current situation, not more permissive, so it can't introduce any new scenario to the solver (e.g. ones which mix 1.8 and 1.9 gems). It can only *reduce* the number of possibilities the solver has to look at.
[snipped]
It creates problem, because you build your gem with ruby 1.8 or 1.9 and what you want to achieve is ensure that rubygem(erubis:2.7) is also built for same ABI. Without ABI version you risk install of gems for different ABIs.
Why do you say "without ABI version" ? I am not suggesting dropping the existing Requires which has the ABI version dependency. Maybe you are missing the fact that rubygem-chef will still have this automatic dependency:
Requires: rubygem(1.9:erubis) >= 0
as seen here:
When this is combined with the *additional* manual dependency which I am suggesting, i.e.
Requires: rubygem(erubis:2.7)
Well, main problem here is that you cannot combine it. if you have Requires: rubygem(1.9:erubis) >= 0 Requires: rubygem(erubis:2.7) It doesn't mean first && second, but satisfy first and satisfy second. It is same as Requires: libA > 1.6 Requires: libA < 1.8 Can result in installation of libA-2.0 and libA-1.0.
then the combination ensures there is no risk of getting the wrong ABI or the Build Service not knowing which version to choose.
So as Idescribe above you need it in one line like: Requires(1.9:erubis:2.7)
BTW we are solving this issue also in OBS and we use in project config prefer keyword - http://en.opensuse.org/openSUSE:Build_Service_prjconf#Prefer eg we have Prefer: rubygem-activesupport-3_2 Prefer: rubygem-activeresource-3_2 Prefer: rubygem-activerecord-3_2 Prefer: rubygem-railties-3_2
OK, great! But that depends on the version-suffixed Provides: symbols which coolo already stated he hopes can be dropped in the future:
http://lists.opensuse.org/opensuse-ruby/2012-07/msg00025.html
Yes, but when it exists then it creates multichoice.
You mean multiple choices of ABIs for the solver, or multiple choices of syntax in prjconf? This is not true for the former. For the latter, although it is true, that is the universal approach to improving API design: a) introduce a new mechanism which deprecates the old one, b) retire usage of the old, and finally c) drop support for the old. So I don't see anything wrong with it.
So when it disappear, then you should not specify which version you need and only dependency in gem should be enough.
When what disappears? Sorry, I don't understand what you meant here.
I mean when old syntax disappear.
I think not for multichoice and I think that it is something that maybe should be solved by build service to automatic make well defined choice when you don't care what package or version is used.
They could have easily made it just choose the newest version. The fact that they didn't suggests to me that there was a good reason for the BS not to make the choice by itself.
I agree with you there. I think that build-service itself should decide it on its own, when package spec file said, that it don't care. Josef -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
Josef Reidinger (jreidinger@suse.cz) wrote:
On Thu, 22 Nov 2012 13:38:29 +0000 Adam Spiers <aspiers@suse.com> wrote:
Josef Reidinger (jreidinger@suse.cz) wrote:
Adam Spiers <aspiers@suse.com> wrote:
Josef Reidinger (jreidinger@suse.cz) wrote:
Adam Spiers <aspiers@suse.com> wrote:
[snipped]
So can someone please explain why having extra automatic Provides: which omit the rubyabi would be asking for trouble?
Because you cannot mix gems from 1.8 and 1.9. So if you have one OBS that builds againts 1.8 and another repo that builds againsts 1.9, then there is potential problem ,that solver can choose mixture of gems, that won't work.
I don't understand that at all. I'm suggesting adding extra Provides: symbols to gem A so that gem B can have extra Requires: on one of those symbols. That is *less* permissive than the current situation, not more permissive, so it can't introduce any new scenario to the solver (e.g. ones which mix 1.8 and 1.9 gems). It can only *reduce* the number of possibilities the solver has to look at.
[snipped]
It creates problem, because you build your gem with ruby 1.8 or 1.9 and what you want to achieve is ensure that rubygem(erubis:2.7) is also built for same ABI. Without ABI version you risk install of gems for different ABIs.
Why do you say "without ABI version" ? I am not suggesting dropping the existing Requires which has the ABI version dependency. Maybe you are missing the fact that rubygem-chef will still have this automatic dependency:
Requires: rubygem(1.9:erubis) >= 0
as seen here:
When this is combined with the *additional* manual dependency which I am suggesting, i.e.
Requires: rubygem(erubis:2.7)
Well, main problem here is that you cannot combine it. if you have Requires: rubygem(1.9:erubis) >= 0 Requires: rubygem(erubis:2.7)
It doesn't mean first && second, but satisfy first and satisfy second. It is same as Requires: libA > 1.6 Requires: libA < 1.8 Can result in installation of libA-2.0 and libA-1.0.
Hmm, do you know for sure that this outcome is possible, or is that just an intelligent guess? I see your point, but http://en.opensuse.org/openSUSE:Libzypp_satsolver_basics#Dealing_with_free_c... says "minimize number of packages to install" which suggests that the solver would prefer to install a single package which satisfies both Requires: rubygem(1.9:erubis) >= 0 Requires: rubygem(erubis:2.7) rather than rubygem-erubis-2_6 built for 1.9 ABI, rubygem-erubis-2.7 built for 1.8 ABI, *and* the ruby 1.8 package(s) which the latter would require (assuming that the ruby 1.8 and 1.9 packages didn't conflict). So I would be really surprised if it chose the latter.
So as Idescribe above you need it in one line like: Requires(1.9:erubis:2.7)
Yes, but then the .spec file is hardcoded to 1.9 *and* 2.7, and the only reason was that the Build Service cannot make up its own mind which one to choose :-/
BTW we are solving this issue also in OBS and we use in project config prefer keyword - http://en.opensuse.org/openSUSE:Build_Service_prjconf#Prefer eg we have Prefer: rubygem-activesupport-3_2 Prefer: rubygem-activeresource-3_2 Prefer: rubygem-activerecord-3_2 Prefer: rubygem-railties-3_2
OK, great! But that depends on the version-suffixed Provides: symbols which coolo already stated he hopes can be dropped in the future:
http://lists.opensuse.org/opensuse-ruby/2012-07/msg00025.html
Yes, but when it exists then it creates multichoice.
You mean multiple choices of ABIs for the solver, or multiple choices of syntax in prjconf? This is not true for the former. For the latter, although it is true, that is the universal approach to improving API design: a) introduce a new mechanism which deprecates the old one, b) retire usage of the old, and finally c) drop support for the old. So I don't see anything wrong with it.
So when it disappear, then you should not specify which version you need and only dependency in gem should be enough.
When what disappears? Sorry, I don't understand what you meant here.
I mean when old syntax disappear.
I see, but multiple choice is inevitable when migrating from an old system to a new system. And as long as we keep using the old style above for Prefer: lines, we will never be able to drop it. -- 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 21. 2012 18:00]:
Josef Reidinger (jreidinger@suse.cz) wrote:
Because you cannot mix gems from 1.8 and 1.9. So if you have one OBS that builds againts 1.8 and another repo that builds againsts 1.9, then there is potential problem ,that solver can choose mixture of gems, that won't work.
I don't understand that at all.
Adam, rubygems carry the Ruby ABI version in their filelist. A rubygem built againts 1.8 provides these files: /usr/lib{64}/ruby/gems/1.8.7/gems/... While a rubygem built against 1.9 provides /usr/lib{64}/ruby/gems/1.9.1/gems/... So while you could install a non-matching rubygem, its files wouldn't be found during runtime. Encoding the Ruby ABI version into the requires/provides prevents this. 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 21. 2012 18:00]:
Josef Reidinger (jreidinger@suse.cz) wrote:
Because you cannot mix gems from 1.8 and 1.9. So if you have one OBS that builds againts 1.8 and another repo that builds againsts 1.9, then there is potential problem ,that solver can choose mixture of gems, that won't work.
I don't understand that at all.
Adam,
rubygems carry the Ruby ABI version in their filelist.
A rubygem built againts 1.8 provides these files: /usr/lib{64}/ruby/gems/1.8.7/gems/...
While a rubygem built against 1.9 provides /usr/lib{64}/ruby/gems/1.9.1/gems/...
So while you could install a non-matching rubygem, its files wouldn't be found during runtime. Encoding the Ruby ABI version into the requires/provides prevents this.
Agreed - but in the text from my mail you snipped, I point out that I am not proposing removing the ABI version from the automatic requires/provides, so this should not be an issue. Please see the rest of the thread, in particular: http://lists.opensuse.org/opensuse-ruby/2012-11/msg00074.html -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
participants (3)
-
Adam Spiers -
Josef Reidinger -
Klaus Kaempf