Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 645890 - app-portage/gentoolkit - Incorrectly states virtual/rubygems dependency is unconditional
Summary: app-portage/gentoolkit - Incorrectly states virtual/rubygems dependency is un...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage Tools Team
URL:
Whiteboard:
Keywords: NeedPatch
Depends on:
Blocks:
 
Reported: 2018-01-27 11:41 UTC by Cedric Sodhi
Modified: 2018-01-27 17:51 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
webkit-gtk overlay ebuild (webkit-gtk-9999.ebuild,823 bytes, text/plain)
2018-01-27 14:40 UTC, Cedric Sodhi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cedric Sodhi 2018-01-27 11:41:37 UTC
`equery depends virtual/rubygems` lists docbook-xsl-stylesheets as an unconditional depender, although according to the ebuild, no dependency on virtual/rubygems should be required with USE=-ruby. I suspect this has something to do with the way the eclass "ruby-single" is inherited, although I'm not sure whether the eclass has a bug or whether it is just used wrongly in this case.
Comment 1 Cedric Sodhi 2018-01-27 11:44:42 UTC
I should add that, even if the verdict turned out to be that a dependency is indeed needed, it will most likely, appropriately be a build-time dependency in this case.
Comment 2 Jeroen Roovers gentoo-dev 2018-01-27 12:11:02 UTC
ruby-single.eclass does not force that dependency, so I am shifting the burden to the docbook-xsl-stylesheets ebuild side. Or maybe equery is getting it wrong?
Comment 3 James Le Cuirot gentoo-dev 2018-01-27 12:45:40 UTC
Sorry but while I made the Ruby changes to this package, I'm going to pass this onto the Portage tools team. Grepping for rubygems in /var/db/pkg/app-text/docbook-xsl-stylesheets-1.79.1-r2 comes up empty and if I look at environment.bz2, the only relevant reference is:

declare RDEPEND=">=app-text/build-docbook-catalog-1.1
        ruby? ( || (  dev-lang/ruby:2.2 dev-lang/ruby:2.3 ) virtual/rubygems ) "

The dependency is clearly conditional here. I don't know why equery states otherwise but I am seeing that too, not just for docbook-xsl-stylesheets but also dev-vcs/subversion, which also uses ruby-single.
Comment 4 Cedric Sodhi 2018-01-27 14:34:47 UTC
Thanks for the hint Jeroen. Indeed, after I --deselect'ed "the real" depender on rubygems, emerge would --depclean rubygems (and others), so apparently emerge does not agree with what equery thinkgs depends on it.
Comment 5 Cedric Sodhi 2018-01-27 14:39:48 UTC
I must ammend my previous comment, though. There is something wrong (as far as I can see) in portage, too. The "real depender" which I mentioned was an overlay ebuild for "webkit-gtk", which only had dev-lang/ruby in DEPEND, but not RDEPEND.

Therefore, ruby should be cleaned out with --depclean, even while "webkit-gtk" is selected. But only if I --deselect "webkit-gtk", dev-lang/ruby and rubygems will  be cleaned.

I don't think this is a mistake in my overlay ebuild, but I'll attach it just to be sure.
Comment 6 Cedric Sodhi 2018-01-27 14:40:29 UTC
Created attachment 516902 [details]
webkit-gtk overlay ebuild
Comment 7 Cedric Sodhi 2018-01-27 14:44:05 UTC
Maybe this has to do with the circular dependency between ruby and rubygems? So although both are effectively only build-time deps, they depend on eachother as run-time deps and therefore refuse to be cleaned?
Comment 8 Brian Dolbec gentoo-dev 2018-01-27 16:34:28 UTC
equery depends is not an accurate means of determining what emerge does in the way of dependencies.  It does not do dependency calculations to evaluate the information it finds in the plain *DEPEND info from the installed ebuilds.

What it does do is use portage code to get the *DEPEND info from the ebuilds and try to follow the deps back to the level determined by the options (using simple rules).  It then spits out that info for matching the pkg string given.   It is by no means absolute.  It is entirely possible to get red-herring data from equery depends that does not match a complex emerge dependency calculation.  So equery will list an ebuild which lists a pkg as an optional dependency, but was never installed with that pkg as a dependency. It is up to the user to read the dep string shown and evaluate if that depending pkg really depends on the pkg being queried. 

There have been a great many dependency calculation changes done in portage since this equery depends code was written. So, it may be possible to work on the reverse depends code to improve it's accuracy, but it will likely be at the cost of increased scan times.
Comment 9 Cedric Sodhi 2018-01-27 16:43:39 UTC
Ok Brian, thanks for the information. Do you suggest I file a separate bug for the fact that ruby and rubygems are not removed by `emerge --with-bdeps=y --depclean`, despite them being build-time dependencies only?
Comment 10 Brian Dolbec gentoo-dev 2018-01-27 17:51:49 UTC
yeah, file a portage bug for those.

I'm marking this one as NeedPatch.  If someone has some time to spend on it, the code could probably use some improvment.

Perhaps an option to re-run the inital output thru emerges's dep calc code to filter out the false positives the first run found.  That would allow the current depends module to be relatively quick, then when more fine-grained and accurate info is needed, run it with the additional filtering.