Discussion:
bug in rubygems dependency strategy
Adam Spiers
2014-04-29 22:40:59 UTC
Permalink
I think I found a bug in our current rubygems automatic dependency
system[0]. It's similar to the problem darix mentioned almost 3 years
ago[1], and I can demonstrate with the real world example I just
found ...

vagrant's upstream .gemspec file contains this dependency range:

s.add_dependency "net-ssh", ">= 2.6.6", "< 2.8.0"

This translates to the following rpm Requires:

auto: rubygem(1.9.1:net-ssh) >= 2.6.6
auto: rubygem(1.9.1:net-ssh) < 2.8.0

Unfortunately the only versions available on 12.3 from d:l:r:e and the
base OS are as follows:

S | Name | Type | Version | Arch | Repository
--+---------------------+---------+-------------+--------+--------------------------------
i | rubygem-net-ssh | package | 2.8.0-26.1 | x86_64 | Ruby Extensions (openSUSE_12.3)
v | rubygem-net-ssh | package | 2.6.1-2.1.1 | x86_64 | openSUSE-12.3-Oss
| rubygem-net-ssh-2_1 | package | 2.1.4-2.7 | x86_64 | Ruby Extensions (openSUSE_12.3)
| rubygem-net-ssh-2_2 | package | 2.2.2-3.7 | x86_64 | Ruby Extensions (openSUSE_12.3)

So in this situation, if I zypper install my vagrant package, I end up
with the following simultaneously installed:

rubygem-net-ssh-2_1-2.1.4-2.7.x86_64
rubygem-net-ssh-2.8.0-26.1.x86_64

The first satisfies the < 2.8.0 requirement, and the second satisfies
the >= 2.6.6 requirement, but neither of them give vagrant what it
really wants. So when I run it, I get:

/usr/lib64/ruby/1.9.1/rubygems/dependency.rb:247:in `to_specs': Could not find net-ssh (< 2.8.0, >= 2.6.6) amongst [RedCloth-4.2.9, [...snipped...], net-ssh-2.8.0, net-ssh-2.1.4, [...snipped...], vagrant-1.5.4, [...snipped...]] (Gem::LoadError)
from /usr/lib64/ruby/1.9.1/rubygems/specification.rb:777:in `block in activate_dependencies'
from /usr/lib64/ruby/1.9.1/rubygems/specification.rb:766:in `each'
from /usr/lib64/ruby/1.9.1/rubygems/specification.rb:766:in `activate_dependencies'
from /usr/lib64/ruby/1.9.1/rubygems/specification.rb:750:in `activate'
from /usr/lib64/ruby/1.9.1/rubygems.rb:1232:in `gem'
from /usr/bin/vagrant:22:in `<main>'

This looks like a fundamental limitation of rpm's version requirement
system, and I can't think of a good workaround right now :-/

Does anyone have a good idea how to fix this? The upstream docs seem
blissfully unaware of the problem[2].

[0] as described by https://en.opensuse.org/openSUSE:Packaging_Ruby#How_gem_dependencies_are_automatically_handled
[1] http://lists.opensuse.org/opensuse-ruby/2011-07/msg00000.html
[2] http://www.rpm.org/wiki/PackagerDocs/MultipleVersions
Adam Spiers
2014-04-29 22:49:13 UTC
Permalink
Post by Adam Spiers
This looks like a fundamental limitation of rpm's version requirement
system, and I can't think of a good workaround right now :-/
Well, s/workaround/solution/ - installing rubygem-net-ssh-2.6.6 from
systemsmanagement:chef:10 is a valid workaround in this particular
case. But I'm looking for something which applies generally to this
problem class.
Stephan Kulow
2014-04-30 05:04:44 UTC
Permalink
Post by Adam Spiers
Post by Adam Spiers
This looks like a fundamental limitation of rpm's version requirement
system, and I can't think of a good workaround right now :-/
Well, s/workaround/solution/ - installing rubygem-net-ssh-2.6.6 from
systemsmanagement:chef:10 is a valid workaround in this particular
case. But I'm looking for something which applies generally to this
problem class.
If you had this problem while writing a spec file, you would write:
Requires: foo >= 2.6.0
Conflicts: foo >= 2.8

Unfortunately we can't generate conflicts.

Greetings, Stephan
--
Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die
ganze Welt an Arsch offen hat, oder grad deswegn.
--
To unsubscribe, e-mail: opensuse-ruby+unsubscribe-***@public.gmane.org
To contact the owner, e-mail: opensuse-ruby+owner-***@public.gmane.org
Stephan Kulow
2014-04-30 06:49:58 UTC
Permalink
On second thought: gem2rpm *can* generate conflicts in this very situation.

Stephan
Post by Adam Spiers
Post by Adam Spiers
Post by Adam Spiers
This looks like a fundamental limitation of rpm's version
requirement
Post by Adam Spiers
Post by Adam Spiers
system, and I can't think of a good workaround right now :-/
Well, s/workaround/solution/ - installing rubygem-net-ssh-2.6.6 from
systemsmanagement:chef:10 is a valid workaround in this particular
case. But I'm looking for something which applies generally to this
problem class.
Requires: foo >= 2.6.0
Conflicts: foo >= 2.8
Unfortunately we can't generate conflicts.
Greetings, Stephan
--
Ma muaß weiterkÀmpfen, kÀmpfen bis zum Umfalln, a wenn die
ganze Welt an Arsch offen hat, oder grad deswegn.
--
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Josef Reidinger
2014-04-30 07:38:57 UTC
Permalink
On Wed, 30 Apr 2014 08:49:58 +0200
Post by Stephan Kulow
On second thought: gem2rpm *can* generate conflicts in this very situation.
Stephan
Yes, it is right, It should not be problem to add it to gem2rpm. If you
do not have time, feel free to open bug and assign it to me, but I
worry that due to high load for SLE12 I do not have time for it for
whole month ( maybe in RC phase )

Josef
Post by Stephan Kulow
Post by Adam Spiers
Post by Adam Spiers
Post by Adam Spiers
This looks like a fundamental limitation of rpm's version
requirement
Post by Adam Spiers
Post by Adam Spiers
system, and I can't think of a good workaround right now :-/
Well, s/workaround/solution/ - installing rubygem-net-ssh-2.6.6
from systemsmanagement:chef:10 is a valid workaround in this
particular case. But I'm looking for something which applies
generally to this problem class.
Requires: foo >= 2.6.0
Conflicts: foo >= 2.8
Unfortunately we can't generate conflicts.
Greetings, Stephan
--
Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die
ganze Welt an Arsch offen hat, oder grad deswegn.
--
Adam Spiers
2014-04-30 11:13:15 UTC
Permalink
Post by Josef Reidinger
On Wed, 30 Apr 2014 08:49:58 +0200
Post by Stephan Kulow
On second thought: gem2rpm *can* generate conflicts in this very situation.
Stephan
Yes, it is right, It should not be problem to add it to gem2rpm. If you
do not have time, feel free to open bug and assign it to me, but I
worry that due to high load for SLE12 I do not have time for it for
whole month ( maybe in RC phase )
https://bugzilla.novell.com/show_bug.cgi?id=875814

I would love to fix it but I am also currently under very high load :-/
Klaus Kaempf
2014-04-30 06:38:26 UTC
Permalink
Post by Adam Spiers
This looks like a fundamental limitation of rpm's version requirement
system, and I can't think of a good workaround right now :-/
A proper fix has to wait for the next version of rpm which is supposed
to support boolean expressions in dependencies.

See


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-***@public.gmane.org
To contact the owner, e-mail: opensuse-ruby+owner-***@public.gmane.org
Josef Reidinger
2014-04-30 07:40:25 UTC
Permalink
On Wed, 30 Apr 2014 08:38:26 +0200
Post by Klaus Kaempf
Post by Adam Spiers
This looks like a fundamental limitation of rpm's version
requirement system, and I can't think of a good workaround right
now :-/
A proper fix has to wait for the next version of rpm which is supposed
to support boolean expressions in dependencies.
See http://youtu.be/fz4GJnFokso
Klaus
Well, it is teoretically correct, but practically not. I think version
with conflict is fine, just result is that you cannot have simulatneous
installed more gems, which is drawback. So when new rpm is released and
we know in which version, then gem2rpm can create conditional conflict.

Josef
Adam Spiers
2014-04-30 11:01:41 UTC
Permalink
Post by Josef Reidinger
On Wed, 30 Apr 2014 08:38:26 +0200
Post by Klaus Kaempf
Post by Adam Spiers
This looks like a fundamental limitation of rpm's version
requirement system, and I can't think of a good workaround right
now :-/
A proper fix has to wait for the next version of rpm which is supposed
to support boolean expressions in dependencies.
See http://youtu.be/fz4GJnFokso
For those in a hurry, start watching from 6'52".
Post by Josef Reidinger
Well, it is teoretically correct, but practically not.
I don't follow; please could you explain this in more detail?
Post by Josef Reidinger
I think version
with conflict is fine, just result is that you cannot have simulatneous
installed more gems, which is drawback. So when new rpm is released and
we know in which version, then gem2rpm can create conditional conflict.
Agreed. Using "Conflicts:" is a kind of evil workaround.
Josef Reidinger
2014-04-30 11:17:42 UTC
Permalink
On Wed, 30 Apr 2014 12:01:41 +0100
Post by Adam Spiers
Post by Josef Reidinger
On Wed, 30 Apr 2014 08:38:26 +0200
Post by Klaus Kaempf
Post by Adam Spiers
This looks like a fundamental limitation of rpm's version
requirement system, and I can't think of a good workaround right
now :-/
A proper fix has to wait for the next version of rpm which is
supposed to support boolean expressions in dependencies.
See http://youtu.be/fz4GJnFokso
For those in a hurry, start watching from 6'52".
Post by Josef Reidinger
Well, it is teoretically correct, but practically not.
I don't follow; please could you explain this in more detail?
OK, probably I am not fully clear. I wanna to say something like it
will work in future, but we need to solve it now.
Post by Adam Spiers
Post by Josef Reidinger
I think version
with conflict is fine, just result is that you cannot have
simulatneous installed more gems, which is drawback. So when new
rpm is released and we know in which version, then gem2rpm can
create conditional conflict.
Agreed. Using "Conflicts:" is a kind of evil workaround.
Yes, it also have drawbacks, so we need to decide if current problem
is bigger then problems from conflicts or not, so we live with current
problems until new rpm will be released.

Josef
Adam Spiers
2014-04-30 11:23:20 UTC
Permalink
Post by Josef Reidinger
On Wed, 30 Apr 2014 12:01:41 +0100
Post by Adam Spiers
Post by Josef Reidinger
On Wed, 30 Apr 2014 08:38:26 +0200
Post by Klaus Kaempf
Post by Adam Spiers
This looks like a fundamental limitation of rpm's version
requirement system, and I can't think of a good workaround right
now :-/
A proper fix has to wait for the next version of rpm which is
supposed to support boolean expressions in dependencies.
See http://youtu.be/fz4GJnFokso
For those in a hurry, start watching from 6'52".
Post by Josef Reidinger
Well, it is teoretically correct, but practically not.
I don't follow; please could you explain this in more detail?
OK, probably I am not fully clear. I wanna to say something like it
will work in future, but we need to solve it now.
Oh OK :)
Post by Josef Reidinger
Post by Adam Spiers
Post by Josef Reidinger
I think version
with conflict is fine, just result is that you cannot have
simulatneous installed more gems, which is drawback. So when new
rpm is released and we know in which version, then gem2rpm can
create conditional conflict.
Agreed. Using "Conflicts:" is a kind of evil workaround.
Yes, it also have drawbacks, so we need to decide if current problem
is bigger then problems from conflicts or not, so we live with current
problems until new rpm will be released.
I agree. My hunch is that introducing Conflicts is better than
leaving the status quo, but I'm not 100% sure.

Loading...