Mailinglist Archive: opensuse-ruby (83 mails)

< Previous Next >
Re: [opensuse-ruby] non-rubyabi-specific gem version dependencies
  • From: Adam Spiers <aspiers@xxxxxxxx>
  • Date: Thu, 22 Nov 2012 23:27:56 +0000
  • Message-id: <20121122232756.GB25751@pacific.linksys.moosehall>
Josef Reidinger (jreidinger@xxxxxxx) wrote:
On Thu, 22 Nov 2012 13:38:29 +0000
Adam Spiers <aspiers@xxxxxxxx> wrote:

Josef Reidinger (jreidinger@xxxxxxx) wrote:
Adam Spiers <aspiers@xxxxxxxx> wrote:
Josef Reidinger (jreidinger@xxxxxxx) wrote:
Adam Spiers <aspiers@xxxxxxxx> 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)

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_choices

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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-ruby+owner@xxxxxxxxxxxx

< Previous Next >