Mailinglist Archive: opensuse-ruby (83 mails)

< Previous Next >
Re: [opensuse-ruby] non-rubyabi-specific gem version dependencies
On Wed, 21 Nov 2012 17:00:40 +0000
Adam Spiers <aspiers@xxxxxxxx> wrote:

Josef Reidinger (jreidinger@xxxxxxx) wrote:
On Wed, 21 Nov 2012 16:21:35 +0000
Adam Spiers <aspiers@xxxxxxxx> 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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-ruby+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups