`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.
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.
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?
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.
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.
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.
Created attachment 516902 [details] webkit-gtk overlay ebuild
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?
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.
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?
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.