Even though it's not strictly a bug, it usually means that the person writing the ebuild has made a mistake: Exhibit A (from mail-filter/dspam): mysql? ( >=dev-db/mysql-3.23 ) || ( >=sys-libs/db-4.0 ) They think they're picking between mysql and db...but they're not. There are currently about 594 instances of "|| ( )" with only one atom inside the parens.
This will require a huge amount of changes all over the place. However, I am planning to put something to this effect into place when repoman is rewritten. Essentially, will collapse all structures that provide no use, get rid of any duplicate atoms and then reconstruct the DEPEND strings. Then mark it as a warning if they differ. I believe the code to do it is working properly but approximately a third of the tree got marked when I did a test. If you twist my arm - and test it a bit - could maybe get it in earlier.
/me twists jstubbs arm. Gimme. If a third of the tree needs to be changed, I'd like to get started sooner rather then later. ;-)
Reopening for consideration
We can add an argument to the portage.dep_check() function that repoman can use to pass in a dict or list for storing warnings like this.
QA should be involved in such stuff. I'm against it. The contents of || () may be auto-generated by eclass. In this case it doesn't make sense to randomly add and remove || () depending on no of atoms inside.
(In reply to Michał Górny from comment #5) > I'm against it. The contents of || () may be auto-generated by eclass. In > this case it doesn't make sense to randomly add and remove || () depending > on no of atoms inside. Yeah, that would be annoying. However, me might want to review use cases for this type of auto-generation, since they might be abusing || deps somehow. For example, we used to have an eclass that used this kind of thing to pull in a range of qt versions, and the deps often had to be updated in-place (which required --dynamic-deps, but now --changed-deps is available as an alternative).
repoman support has been removed per bug 835013. Please file a new bug (or, I suppose, reopen this one) if you feel this check is still applicable to pkgcheck and doesn't already exist.
