stefan11111 <stefan11111@shitposting.expert> wrote: > On 2023-12-28 15:21, Martin Vaeth wrote: >> stefan11111 <stefan11111@shitposting.expert> wrote: >>> This got me wondering though, is there no way to fix this globally >>> via make.conf instead of adding patched ebuilds to my overlay? >> >> No. Until https://bugs.gentoo.org/209653 is fixed (which did not >> happen since 16 years and presumably never will), there is no >> other way to fix dependencies than to copy the ebuild to some >> overlay. > Interesting read. > Would be nice is there was a way to set PYTHON_COMPAT through > envvars/make.conf vars like MYMESONARGS.
This is not possible, the reason being implicitly explained in the above bug: PYTHON_COMPAT is used to calculate the dependencies from the ebuild which are package metadata. And this metadata must have been already calculated when portage is started: if the ebuild would have to be interpreted whenever the metadata is needed, portage would be unbearable slow. Bot to speak about difficulties with things like tbz2 files which in general only contain the metadata and not necessarily the ebuild anymore. This is the reason why the emerge --regen and emerge -u ... phases are practically disjoint (and why emerge --metadata takes ages, in general, unless you use a repository with already generated metadata). > This seems like such an easy fix too. Just set PYTHON_COMPAT > to include python 3.12 and be done with it. What you can do is the modify the corresponding eclass(es) to auto-add python 3.12 to PYTHON_COMPAT. After that change to take effect on the metadata, you have to call emerge --regen for the main gentoo repository. Note however, that - roughly speaking - this way you have made your own "overlay" of the gentoo repository, and you have to think of a way how to sync/merge your modification with the gentoo repository regularly. At the very least, you have to call the processor- and time-consuming emerge --regen after every syncing. Keeping some dozens packages in a "regular" overlay is much simpler than practically maintaining all packages in a local overlay... > Another thing would be if adding dev-lang/python-3.11.7 to > package.provided only made portage pretend that > dev-lang/python-3.11.7 is installed, and not every version > of python3. For portage, this trick would almost work, but portage would resolve dependencies falsely and e.g. not recompile packages which should be recompiled to work with python:3.12. Also, USE-dependencies with python versions (e.g. python_targets_python3_11) could not be resolved as you cannot package.provide USE-flags. Moreover, even if the dependency problem could be solved, the ebuilds would fail nevertheless if e.g. python-3.12 is not in PYTHON_COPMPAT when it should be for several reasons: 1. The eclass would check whether the python:3.11 version is present and use that for compilation. 2. The result would be put into the directory for the python:3.11 version where python-3.12 does not find it. > Or if we had an easy way to patch ebuilds like we have > /etc/portage/patches... /etc/portage/patches can patch practically everything in ebuilds *except metadata*. That's exactly what bug 209653 is about.
