[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-user
Subject:    Re: [gentoo-user] Re: Python 3.11 USE flags being flipped on
From:       stefan11111 <stefan11111 () shitposting ! expert>
Date:       2023-12-28 22:59:57
Message-ID: ebe19fe2117aeb2902f82789f5e5943b () shitposting ! expert
[Download RAW message or body]

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"

[prev in list] [next in list] [prev in thread] [next in thread]