On 2023-12-28 20:23, Martin Vaeth wrote:
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.
I see.
Should I at least file bugs about those packages?
Surely there is no reason to artificially limit the python version in
::gentoo?
--
Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-7400_CPU_@_3.00GHz
COMMON_FLAGS="-O3 -pipe -march=native -ftree-vectorize -ffast-math
-funswitch-loops -fuse-linker-plugin -flto -fdevirtualize-at-ltrans
-fno-plt -fno-semantic-interposition -fno-common -falign-functions=32
-fgraphite-identity -floop-nest-optimize"
USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto
libressl olde-gentoo asm native-symlinks threads jit jumbo-build minimal
strip system-man"
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd
/usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus
/lib/udev /usr/share/icons /usr/share/applications
/usr/share/gtk-3.0/emoji /usr/lib64/palemoon/gtk2"
