#331 ruby guidelines requiring ruby(release) causes depsolving headache
Closed: Fixed None Opened 6 years ago by mattdm.

If one installs a minimal Fedora and then does 'yum install puppet', both jruby and regular ruby are selected, pulling in over 100 packages weighing in at 200MB.

Puppet can work with jruby (although I don't think that's supported officially), but we don't want it to be the default. And, in this case, it's not actually even being used. The puppet package has an explicit "Requires: ruby" as suggested, which causes regular ruby to be installed, but yum hits this in depsolving:

{{{
--> Processing Dependency: ruby(release) for package: puppet-3.1.1-5.fc19.noarch
Searching pkgSack for dep: ruby(release)
TSINFO: Marking jruby-1.7.2-1.fc19.noarch as install for puppet-3.1.1-5.fc19.noarch
}}}

Them, the ruby package is selected ''later'' in the depsolving process; it would also fill the ruby(release) req, of course, but by then it's too late.

Arguably this is a depsolving bug, but I can't see how it could be fixed without multiple depsolving passes, which I think no one would be a fan of.

One possible workaround would be to make the ruby(release) requirement optional when Requires: ruby is used.

Another other would be to make packages which want to use jruby do so only explicitly, and to not have jruby offer the virtual provides.


I filed the RPM request at https://bugzilla.redhat.com/show_bug.cgi?id=994204 -- maybe that will provide a solution.

And I cc'd Sam on this ticket because he's looking into the larger jruby issue.

Them, the ruby package is selected later in the depsolving process; it would also fill the ruby(release) req, of course, but by then it's too late.

One workaround here is that yum sorts the order it processes the requirements in, so you can make it process the ruby one first. I'm not sure how much this is documented, but the magic happens in _sort_req_key() and basically means that if you do:

Requires: ruby >= 1.9.0

...that will be processed before:

Requires: ruby(release)

Replying to [comment:3 james]:

One workaround here is that yum sorts the order it processes the requirements in, so you can make it process the ruby one first. I'm not sure how much this is documented, but the magic happens in _sort_req_key() and basically means that if you do:

Is this magic likely to ''stay'' true? It's certainly the easiest fix — just change the guidelines to say that

Requires: ruby > 0

is the incantation required to get a specific ruby interpreter. But if a new version of yum (or dnf) might change the behavior....

It's pretty much guaranteed to stay true in yum (I thought we'd even documented it, but I can't find it atm) ... other package managers don't do this though.

A bug in yum that would have prevented the versioned requires from working has recently been fixed: https://bugzilla.redhat.com/show_bug.cgi?id=998707 we talked to samkottler in today's meeting. I think we understand the issue a little better but we still need to come up with a solution. I think there was some discussion of whether we should throw out the concept of sharing the ruby libraries between ruby stacks (due to the level of incompatibility between jruby and ruby) but there's also the possibility of trying to just fix the Requires to make specifying which specific ruby interpreter to use work correctly.

At this time I'm unsure of the general feeling towards either of these possibilities by either FPC or the ruby sig. (In part, because we don't know for sure how easy the latter fix would be [Do we just need Requires: ruby > 0 at this point?] or the level of incompatibility that we're actually talking about. 5% of packages? 25%?). Hoping that samkottler and others can provide more information in this ticket (and ticket 334 if applicable) over the course of this week.

Bug in YUM is bug in YUM and that is orthogonal to the compatibility among Ruby implementations.

Anyway, I have no problem with dropping ruby(release) if package explicitly depends on Ruby package. However, this should be exceptional and discouraged practice IMO.

I'm still cleaning up old tickets. I don't think there's any specific proposal that the committee can address here. Could someone provide one, or let us know what still needs to be done?

No response; closing. Please feel free to reopen if you have more information to add.

Login to comment on this ticket.

Metadata