Check for packages that block the upgrade of their dependencies

[hololeap]

This is a proposal for a "soft" version of NonsolvableDepsIn*, which would detect when a package is forcing an old version of a dependency to be pulled in, even though a new version of the dependency is available.

Whereas NonsolvableDepsIn* would be triggered if the specified dependency did not exist, this proposed check would be triggered if the dependency specification requires an old version of a dependency to be pulled in.

This is somewhat related to RedundantVersionCheck, except it would be triggered when another package would force a redundant version into the dependency graph.

Example:

• app-misc/x/x-1.2.3.ebuild:

  ...
  KEYWORDS="~amd64 ~x86"
  RDEPEND="
  	>=app-misc/y-2.3 <app-misc/y-2.4
  "
  ...
  

• app-misc/y/y-2.3.4.ebuild:

  ...
  KEYWORDS="~amd64 ~ppc64 ~x86"
  ...
  

• app-misc/y/y-2.4.5.ebuild:

  ...
  KEYWORDS="~amd64 ~x86"
  ...
  

---

In this example, app-misc/x would pull in app-misc/y-2.3.4 even though app-misc/y-2.4.5 is available for all of its KEYWORDs. This could be intentional, however it could be that the upper bound in x-1.2.3.ebuild is unneeded.

This happens a lot in Haskell where the Package Versioning Policy asks for developers to pessimistically set upper bounds on every dependency specification. The hackport tool translates these dependencies directly when it generates ebuilds from .cabal files, so ::haskell ends up with a lot of upper bounds that may or may not reflect what the package actually needs to build.

(There has been discussion about hackport ignoring upper bounds when it generates the ebuilds, but the fact is ::haskell has this in almost every current package.)

I propose an optional warning to check for this so that it will be easier for the ::haskell team to detect ebuilds that may have unnecessary upper bounds in their dependency specs, which will ultimately cause portage to skip upgrades of dependencies as it tries to satisfy the dependency graph.

[thesamesam]

A few more notes:

1. If we do this, it should probably not be a default Check, because it'll be expensive. But that's fine.
2. Finding these is important not just to allow cleanups, but for the reason @hololeap says - you end up with skipped upgrades caused by these, and with enough of them, Portage can become very slow as it has to backtrack a large amount, or may not be able to reach a solution at all.
3. This style of issue can lead to an issue where a large number of users can't upgrade because e.g. something got stabled without something else, and it's not something CI detects right now. So it's valuable in a few ways.

[mgorny]

I don't think it's that expensive, if we apply it only to dependencies with <, <=, = operators.

[mgorny]

(and it's quite similar to how we check for USE flags without (-) (+) defaults)

[thesamesam]

(and it's quite similar to how we check for USE flags without (-) (+) defaults)

Oh, duh. Good point.

[hololeap]

I had an odd idea: share code between this and another check that would warn that e.g. y-2.4.5 is missing the ~ppc64 keyword. I would think that you could get both for the price of one since they both have to inspect the KEYWORDS of a package and its dependencies. That could help as a reminder of what arches need to be tested on a given package (that were tested in a previous version).

Edit:

Maybe not the best idea but food for thought.