Replace use of `has_version` with appropriate `python_has_version` in `python_check_deps()`

[Kangie]

This PR addresses an issue that I encountered cross-compiling kde-framework/breeze-icons where an incorrect has_version call fails to correctly locate python dependencies resulting in a failed build.

Looking at the guide python_has_version should be preferred if the python-any-r1 eclass is in use. ~~If python-r1 is in use instead I've just tidied up usage of has_version.~~ Fun fact: I just learnt that python_has_version comes from python-utils-r1, so I'll go back and amend any commits where has_version is used in python_check_deps().

I've also taken the time to do any required cleanup since I'm already looking at....200 odd ebuilds.

• EAPI bumped where trivial
• python 3.11 added to PYTHON_COMPAT
• unused / should not have been inherited eclasses removed

Packages were identified by running grep -rsinl python_gen_any | xargs grep -L "has_version -b" over ::gentoo.

For @thesamesam

[Kangie]

I figured that it was time to make the QA bot unhappy.

I've got a good few packages / ebuilds / versions to go through, and while I've compiled a good number of these (particularly with more complex python_check_deps() functions) I can't be sure that nothing is broken yet, so please do not merge.

[gentoo-bot]

Pull Request assignment

Submitter: @Kangie Areas affected: ebuilds, other files Packages affected: app-crypt/tpm2-tools, app-doc/gimp-help, app-doc/mathjax-docs, app-i18n/libkkc-data, app-shells/bash-completion...

@gentoo/github: Too many disjoint maintainers, disabling auto-assignment.

Linked bugs

No bugs to link found. If your pull request references any of the Gentoo bug reports, please add appropriate GLEP 66 tags to the commit message and request reassignment.

If you do not receive any reply to this pull request, please open or link a bug to attract the attention of maintainers.

---

In order to force reassignment and/or bug reference scan, please append [please reassign] to the pull request title.

Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide

[Kangie]

Also, noting that python_has_version comes from the python-utils-r1 eclass, and is

A convenience wrapper for has_version() with verbose output and better defaults for use in python_check_deps().

I'd like to suggest looking into enabling a QA rule for using python_has_version in python_check_deps() (or the inverse, no has_version in there.)

It would be interesting to look into amending python_has_deps so that it can accept an array to make handling use flags easier, but one thing at a time.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-06-01 13:06 UTC Newest commit scanned: e37f9113acd0af566bcb1a44f9a48aad718c9df2 Status: :white_check_mark: good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question: https://qa-reports.gentoo.org/output/gentoo-ci/6c29c61a7b/output.html

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-06-01 15:01 UTC Newest commit scanned: 193b34c7839a85c56ef8c0a62362f980457a23df Status: :white_check_mark: good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question: https://qa-reports.gentoo.org/output/gentoo-ci/cff5c0a1cd/output.html

[Kangie]

I think I missed a couple of copyright headers, but aside from trivial edits to a few commits for QA this should be done (as long as everything compiles after some sleep)

[Kangie]

Appreciate the feedback, will look into addressing after some sleep.

Agree that commit messages could use some rework, I started this branch fixing an issue I had in crossdev and it stuck. Arguably a lot of these packages would have experienced similar breakage in crossdev based on troubleshooting I did earlier - lots of python BDEPENDS that were being looked for as DEPENDS. I suspect that the issue is masked somewhat as it's likely that the packages in question will exist in the host and target environment.

Not particularly worried if this doesn't get merged in a single PR - now that I've broken the back of the task I can cherry pick commits in small batches and address feedback as I go, I just wanted to get it all out of the way!

Let me know what you think a logical way to break it all up is and once I've addressed any feedback I can get started on that.

[mgorny]

Well, I would start by trying to find large groups of packages with the same maintainer, so people wouldn't have to look through a long list of commits to find something relevant to them. And keep it, say, below 20 packages. And don't file it all at once.

[thesamesam]

I'd say it's fine to do a mega PR as a starting point but we'll have to split it to effectively merge + review for EAPI changes and stuff:

[20:12:53]  <@sam_> Kangie: I have a cheesy script to take a branch and cherry-pick by maintainer
[20:13:16]  <@sam_> it's useful for situations like this where it's easier to fix everything and then worry about maintainership later
[20:13:28]  <@sam_> https://github.com/thesamesam/sam-gentoo-scripts/blob/main/git/rebase-filter-maint

I did this a lot before (and still do sometimes)

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2022-06-04 04:36 UTC Newest commit scanned: 6393b41faea40b3f9ea16b1e1f385feb5266394f Status: :x: broken

New issues caused by PR: https://qa-reports.gentoo.org/output/gentoo-ci/c269e9674d/output.html#net-misc/rabbitmq-server

There are existing issues already. Please look into the report to make sure none of them affect the packages in question: https://qa-reports.gentoo.org/output/gentoo-ci/c269e9674d/output.html

[thesamesam]

Would you mind taking this PR and say, splicing it into the python@ maintained packages so we can get some of it in? I can handle the other nits.