gles2 use changed? can't get dependencies for pyside2

[clytle374]

It appears that something has changed in use with gles2 and gles2-only. I can't get portage resolve this. Been fighting it a couple days and it's above my level. Had to remove pyside and shiboken to update as I had a ton of blocks.

`emerge pyside2 pyside2-tools shiboken2 -pv These are the packages that would be merged, in order:

Calculating dependencies... done!

emerge: there are no ebuilds built with USE flags to satisfy ">=dev-qt/qtgui-5.14:5[gles2?]". !!! One of the following packages is required to complete your request:

• dev-qt/qtgui-5.14.1-r4::gentoo (Missing IUSE: gles2) (dependency required by "dev-python/pyside2-5.14.1-r1::raiagent" [ebuild]) (dependency required by "dev-python/pyside2-tools-5.14.1::raiagent" [ebuild]) (dependency required by "pyside2-tools" [argument]) `

Thanks Cory

[clytle374]

This might be a duplicate. My apologies if so, in my defense searching gles2 didn't return any results.
And I'm not getting a build failure https://github.com/leycec/raiagent/issues/83

[leycec]

Ugh. I can only commiserate with your misery. I really wish Gentoo developers would try to preserve backward compatibility by treating USE flags like a public API, but... here we are, deep within the bowels of emerge dependency resolution hell. </sigh>

This is a stupidly severe issue, so I'm attempting to resolve this tonight. Yikes!

[leycec]

I've chosen to adopt @CaptainBloodz's proposed changeset mostly as is, as everything seems sensible and (most importantly) now resolves correctly. Kudos to the bloody captain! Yar, matey. :skull_and_crossbones:

@a17r: Excellent catch. Luckily for us, the behind-the-scenes differences between gui? ( >=dev-qt/qtgui-${QT_PV}[gles2-only?] ) and gui? ( >=dev-qt/qtgui-${QT_PV}[gles2-only=] ) are mostly neglible. The = USE flag operator is useful when an upstream ebuild enables a USE flag by default that a downstream ebuild (i.e., us) wants to then disable unless users explicitly enable that same USE flag on that downstream ebuild. In other words, it enforces USE flag uniformity across all installed packages on a system.

I'm not a big fan of uniformity. I use Gentoo, which is... like, digital chaos incarnate! Anything goes, right? So, I'm quite O.K. with users disabling gles2-only on PySide2 but enabling gles2-only on qtgui. Whatever floats your Linux boat, users.

[leycec]

Fixed by 599629001cf2a. Sadly, I can't meaningfully test this. emerge refuses to enable gles2-only on either PySide2 or qtgui – presumably because it prefers the full OpenGL stack. Well, we can hardly blame it, can we?

If this is still broken, please reopen this. For now, I foolishly assume this is actually working. If someone smarter than me (...that should be all of you) has any insight on how to enable gles2-only without breaking the world, please enlighten me and I'll test this properly.

[a17r]

I really wish Gentoo developers would try to preserve backward compatibility by treating USE flags like a public API, but... here we are, deep within the bowels of emerge dependency resolution hell.

PMS has no backward compatibility for use flag renaming. The only thing you achieve by keeping old versions with old use flag names around is more cryptic emerge conflicts for users, double effort on every reverse dependency, and the odd overlay will either get it wrong or be broken anyway when the last compatibility version is dropped in, say, one month afterwards. So best you make a clean cut.

That there may be some lag for overlays to execute the change is something every user must be aware of when adding them.

[leycec]

Fair arguments, certainly. As an overlay maintainer, I fundamentally disagree – but that's the nature of the development beast. You can't please everyone, but distros with dwindling volunteer resources like Gentoo can't even please a vocal minority of everyone. So it goes.

Everything that follows is mere wishful thinking. Let a neckbeard dream and hope for better days!

PMS has no backward compatibility for use flag renaming.

Yes, but... it probably should. My contention is that USE flags (along with other obvious metadata like package names, slots, and so on) comprise the public API of an ebuild. Regardless of language or context, open-source public APIs should always be preserved as much as pragmatically feasible for all of the obvious reasons.

The exact opposite is currently the case in Gentoo Land.™ The public API of official upstream ebuilds and eclasses is frequently and unapologetically broken, significantly complicating the volunteer effort for unofficial downstream overlays like this.

The only thing you achieve by keeping old versions with old use flag names around...

...is preserving backward compatibility, which has intrinsic value in and of itself. Rather than forcing already stressed Gentoo developers to preserve old ebuild versions and USE flags in perpetuity (which no one wants), I instead propose some sort of formal mechanism resembling semver (i.e., semantic versioning) for the Gentoo ecosystem. The current "anarchists knows anything goes" approach squanders scarce developer resources on trivial global renames and mundane bureaucratic chores. We can and should do better.

We currently automate backward compatibility for package renames via profiles/updates/, for example. There's no pragmatic reason we couldn't extend the same support to USE flag renames and drop-in eclass replacements as well. Bonus points if we then tie these extensions into a semver-like schema – perhaps by augmenting the current -rN suffix for ebuild versions (e.g., pyside2-5.14.1-r2.ebuild, the second version of the PySide2 5.14.1 ebuild) with additional metadata (e.g., pyside2-5.14.1-r2.2.ebuild, the second patch version of the second major version of the PySide2 5.14.1 ebuild) notifying downstream ebuilds of breaking changes introduced in the public API exposed by upstream ebuilds.

[a17r]

pkgmoves provide no backward compatibility at all. Overlays that do not follow suit are broken.

[a17r]

The exact opposite is currently the case in Gentoo Land.™ The public API of official upstream ebuilds and eclasses is frequently and unapologetically broken, significantly complicating the volunteer effort for unofficial downstream overlays like this.

No, in general, eclass API is not broken, especially for general purpose eclasses. We use EAPI bumps to do that. That's certainly not the case for ebuilds, but there it is a very unrealistic expectation.

As long as the lamenting does not produce actual solutions, and then overlay maintainers subscribe to some miraculous notification mechanism telling them about deprecations inside their ebuilds, we've got to work with what we have. In practise, there is no getting around to overlay maintainers having to play a catch-up game to gentoo.git. And they can avoid that by getting their stuff into gentoo.git.