RdependChange is unnecessarily emitted when PYTHON_COMPAT is updated

[eli-schwartz]

Packages regularly get PYTHON_COMPAT updated with new impls,.and pkgcheck then complains that the ebuild has been modified and RDEPEND has changed without a revbump to force the RDEPEND to be propagated to installed user systems.

But PYTHON_COMPAT always adds new RDEPEND in the form:

USE+="
    python_targets_python3_14
"
RDEPEND+="
    python_targets_python3_14? (
        dev-lang/python:3.14
    )
"

... hence it's inaccurate to claim that a revbump is needed to propagate metadata changes. Furthermore, it's undesirable to revbump. We generally don't, and in cases where the ebuild doesn't need patches to ensure tests pass for the new python implementation, avoiding revbump+30day+stablereqs means we can actually get the whole ecosystem ported in a timely manner. It also means that for example when other packages have an optional dependency on python (and use python modules), we aren't forced to make an "either or" decision about whether to enable new python versions (that depend on additional unstable-only packages) or successfully stable a trivial bugfix which does legitimately need a revbump but there is already a revbumped unstable package doing nothing but adding PYTHON_COMPAT. We could of course revbump yet again with an urgent bugfix, drop python support, stable that, then revbump yet again with new PYTHON_COMPAT but that sounds incredibly painful.

Generically, the issue here is that USE-dependencies that can only be enabled together with enabling a USE flag newly added to the package in the same commit that added the dependencies, should not trigger this warning. It just mostly occurs for python since all PYTHON_TARGETS are guaranteed to act like (-) use, not like (+) use. So we know that the RdependChange that is being warned about is only applicable to users who have rebuilt with a newly enabled USE flag.

[eli-schwartz]

I'm filing this because I've seen it happen a bit too often that users contribute a PR to update to a new PYTHON_COMPAT, add a revbump, and upon being asked why they revbumped, they reply "I didn't want to revbump, there's no good reason to do so here, and originally I tried without it, but pkgcheck told me I have no choice and must do the revbump, so I did the revbump".

Then the PR gets merged anyway. ;)

[arthurzam]

Sounds good to me, but I want extra input

@mgorny @thesamesam I'm giving you time to formulate a reply for the idea, so I know if to go on or abort.

[mgorny]

Isn't it a warning only, though?

Mixed feelings here. As long as the target's stable-masked, that's fine. Once it's unmasked, I'm not so sure.

[thesamesam]

If we add any patches to the ebuild, we should revbump usually unless it's test-only. Otherwise I think it's a good idea to suppress the warning if the only changes were to PYTHON_COMPAT.

Isn't it a warning only, though?

I find people see it and revbump as a result quite often (or ask about it as a result).

[eli-schwartz]

Yes, it is "only" a warning. But people who are conscientious about warnings are usually some of our best and most prolific contributors...

I don't see what this has to do with the target being stable-masked. Stable-masking just affects whether users are allowed to rebuild the package with changed USE. Either way they must rebuild the package, and either they must modify package.use (it still defaults to off for several months even after being unmasked) or else even an emerge -uDN will leave both impls installed. For single_target packages, modifying package.use is mandatory since you have to have at least one impl enabled before, and you can't have two enabled after.

But regardless, I don't see a difference between rebuilding because of a revbump or because of adding a new USE flag. If you've enabled the USE flag, changed-deps will force it to rebuild. If you didn't enable the USE flag, the revbump will rebuild against the old impl and you will not even notice that a new impl is available.

Note the devmanual explicitly says that adding a new USE flag "if it controls a USE dependency where the functionality was hard disabled before" doesn't require a revbump -- and that's exactly the case for python impls.

[thesamesam]

I agree, I think the stable-masked element is tangential.

If we're patching for changes, we should be revbumping either way (regardless of it being stable-masked or not). if we're making changes purely in PYTHON_COMPAT, it should make no difference.

Why should it matter?

[ferringb]

Where all does the content of PYTHON_COMPAT get expanded into, in terms of ebuild exported metadata? The handful of ebuilds I traced, it seemed to just be BDEPEND. If so, this sort of change wasn't why the "must revdep" rule came about. I say that from the PM angle, just to be clear.

If the BDEPEND isn't encoded in any fashion into the artifact- which BDEPEND should not be in a meaningful way- I don't see why this should be a warning if the PYTHON_COMPAT change was expanding it into a superset. Even a subset doesn't seem hugely relevant, as long as it doesn't screw over the globally resolvable depgraph. IMO.

Y'all work w/ these eclasses and ebuilds as maintainers, I don't. What am I missing in my quick skim?

[eli-schwartz]

It is expanded by distutils-r1.eclass into:

• a default-disabled USE flag
• the ${PYTHON_USEDEP} eclass variable used in RDEPEND of the form: RDEPEND=" dev-python/foolib[${PYTHON_USEDEP} "
• any user ebuild invocations of functions like python_gen_cond_dep, which produce use? ( ... ) dependency blocks for the intersection between PYTHON_COMPAT and the pattern filter passed to the eclass function, for cases where only a subset of PYTHON_COMPAT actually needs a particular dependency (this is usually either an RDEPEND or a test? ( .... ) BDEPEND).

Depending on the ebuild in question, it might be using the BDEPEND-only eclass python-any-r1.eclass instead, which also uses PYTHON_COMPAT but produces any-of groups instead of USE dependencies. I'm guessing that's probably the examples you found first?