Checking for blockers without a solution

[thesamesam]

This one is a bit tricky and it's hard to phrase the situation I'm thinking of properly.

The best example I can give is from a recent mistake I made. In a hurry, I bumped glib to dev-libs/glib-2.74.4, but I didn't bump dev-util/gdbus-codegen-2.74.4 and dev-util/glib-utils-2.74.4 with it. glib has a blocker in its RDEPEND as !<dev-util/gdbus-codegen-${PV} (or approximately so).

Portage will rightly schedule an upgrade to dev-libs/glib-2.74.4 but then find it can't install it because e.g. dev-util/gdbus-codegen-2.74.3 is installed with no upgrade queued and new glib blocks it.

A warning to the effect of "This is going to trigger blockers and there's no solution other than not-upgrading" would be useful.

[thesamesam]

I'll note that the obvious counterpoint is that this is not the intended use of blockers. Maybe we should just find cases like this and fix them in Gentoo. Blockers as things stand in PMS are not intended to affect dependency resolution. Plus Portage's handling of them isn't very sophisticated (Portage will almost never, if never, backtrack to skip a blocker, and even then, the semantics of this is poorly defined.)

It occasionally happens with bigger migrations, like say, e2fsprogs & e2fsprogs-libs. It was easy to forget to stabilise a package which had a newer version that had RDEPEND="sys-fs/e2fsprogs" or RDEPEND="|| ( ... )", so you'd only find these stragglers when you try to cleanup e2fsprogs-libs.

In the case of glib, we could just have it so gdbus-codegen just RDEPENDs on the same version of itself in dev-libs/glib, and so on.

[thesamesam]

I can't think of a way to pose this that excludes legitimate blocker uses. Maybe it is just abuse.