emerge getting out because missing python_single_target

[samuelbernardo]

After last eix-sync, for each time I try to "emerge -uDNa @world" it's giving conflict for every installed ebuild that only supports python2.7:

Code: Select all

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-lang/perl:0

  (dev-lang/perl-5.30.1:0/5.30::gentoo, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (dev-lang/perl-5.28.2-r1:0/5.28::gentoo, installed) pulled in by
    dev-lang/perl:0/5.28= required by (dev-perl/PlRPC-0.202.0-r3:0/0::gentoo, installed)
                 ^^^^^^^^                                                                                                   
    (and 162 more with the same problem)

NOTE: Use the '--verbose-conflicts' option to display parents omitted above


!!! The ebuild selected to satisfy "=app-editors/pluma-1.22*" has unmet requirements.
- app-editors/pluma-1.22.0::gentoo USE="introspection -spell -test" ABI_X86="(64)" PYTHON_SINGLE_TARGET="-python2_7" PYTHON_TARGETS="python2_7"

  The following REQUIRED_USE flag constraints are unsatisfied:
    python_single_target_python2_7

  The above constraints are a subset of the following complete expression:
    exactly-one-of ( python_single_target_python2_7 ) python_single_target_python2_7? ( python_targets_python2_7 )

(dependency required by "mate-base/mate-1.22::gentoo[extras]" [installed])
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])

This is just an example that I'm collecting and is anoying since even with --ask emerge flag it exits after first installed ebuild is found. I already have
In /etc7profile/make.conf I have

Code: Select all

PYTHON_TARGETS="python2_7 python3_5 python3_6"
PYTHON_SINGLE_TARGET="python3_5"

[Moderator edit: changed [quote] tags to [code] tags to preserve output layout. -Hu]

[Ionen]

Given this is the 3rd similar report I see of this in a short time frame on different packages (also see this unsolved thread for reference, another user with a similar issue on 3rd post), I'm inclined to believe this isn't user error and there's something broken. But I'm unable to reproduce, anyone has any ideas? There were some changes to the python-single-r1.eclass ~2 days ago which I guess could be related.

[fedeliallalinea]

There is other similar problem in the forum, but I don't know why in your system not set python_single_target_python2_7 automatically, in my system

Code: Select all

[ebuild  N     ] app-editors/pluma-1.22.0::gentoo  USE="introspection spell -test" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" 3,160 KiB

and

Code: Select all

PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6"

Try to resync to see if problem gone

[proteusx]

Same here with 30+ packages affected.

Code: Select all

# emerge -uDNa world
!!! Problem resolving dependencies for app-misc/mtail from @selected

!!! The ebuild selected to satisfy "app-misc/mtail" has unmet requirements.
- app-misc/mtail-1.2.0::gentoo USE="" ABI_X86="(64)" PYTHON_SINGLE_TARGET="-python2_7" PYTHON_TARGETS="python2_7"

  The following REQUIRED_USE flag constraints are unsatisfied:
    python_single_target_python2_7

  The above constraints are a subset of the following complete expression:
    exactly-one-of ( python_single_target_python2_7 ) python_single_target_python2_7? ( python_targets_python2_7 )

(dependency required by "@selected" [set])
(dependency required by "@world" [argument])

O.K. let's add this to package.use:

Code: Select all

 app-misc/mtail PYTHON_SINGLE_TARGET: -* python2_7

Then another one fails:

Code: Select all

!!! The ebuild selected to satisfy "app-text/calibre" has unmet requirements.
- app-text/calibre-4.5.0::gentoo USE="-ios -udisks" ABI_X86="(64)" PYTHON_SINGLE_TARGET="-python2_7" PYTHON_TARGETS="python2_7"

  The following REQUIRED_USE flag constraints are unsatisfied:
    python_single_target_python2_7

  The above constraints are a subset of the following complete expression:
    exactly-one-of ( python_single_target_python2_7 ) python_single_target_python2_7? ( python_targets_python2_7 )

(dependency required by "@selected" [set])
(dependency required by "@world" [argument])

And then another, and another,...... Fschk!
This is ridiculous. Am I going to be here until Kingdom come?

It seems that the "new style" python-single-r1.eclass for some reason it adds a "python_single_target_pyhon2_7" use flag to every ebuild that has USE="python_targets_python2_7" . For example:

Code: Select all

equery u app-misc/mtail
[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for app-misc/mtail-1.2.0:
 U I
 - + python_single_target_python2_7 : Build for Python 2.7 only
 + + python_targets_python2_7       : Build with Python 2.7

As a workaround, I copied an older version (from last weeks portage snapshot) of "python-single-r1.eclass" to /usr/portage/eclass/ and the problem went away.

However, now I need to fathom this error message:

Code: Select all

!!! The following installed packages are masked:
- app-cdr/cdemu-3.2.3::gentoo (masked by: invalid: RDEPEND: Invalid atom (Invalid use dep: '${PYTHON_MULTI_USEDEP}'), token 20 in '/var/db/pkg/app-cdr/cdemu-3.2.3/RDEPEND')
- app-eselect/eselect-repository-7::gentoo (masked by: invalid: RDEPEND: Invalid atom (Invalid use dep: '${PYTHON_MULTI_USEDEP}'), token 21 in '/var/db/pkg/app-eselect/eselect-repository-7/RDEPEND')

At least this is only a warning and it does not stop the emerge, which is a good thing.

[asturm]

If you have been setting PYTHON_TARGETS and PYTHON_SINGLE_TARGET inside /etc/portage/make.conf, you should move this to /etc/portage/package.use. This has been the recommendation for years.

https://wiki.gentoo.org/wiki/Project:Py ... ON_TARGETS

[proteusx]

If you have been setting PYTHON_TARGETS and PYTHON_SINGLE_TARGET inside /etc/portage/make.conf, you should move this to /etc/portage/package.use. This has been the recommendation for years.

These are set in /usr/portage/profiles/base/make.defaults

Code: Select all

# Mikle Kolyada <zlogene@gentoo.org> (2018-07-24)
# Updated to python3_6
PYTHON_TARGETS="python2_7 python3_6"
PYTHON_SINGLE_TARGET="python3_6"

The whole of "PYTHON TARGETS" is crazy, convoluted and labyrinthine.
From reading the ebuild it is impossible to tell what are the python use flags and you need delve into the eclass spaghetti.

[asturm]

You can certainly derive from ebuilds what is *supported*, however standard settings and masks are of course applied globally.

These are set in /usr/portage/profiles/base/make.defaults

Of course they are.

[slackline]

I've hit this problem too and as @astrum correctly surmised I've set PYTHON_TARGETS and PYTHON_SINGLE_TARGET in /etc/portage/make.conf...

Code: Select all

PYTHON_TARGETS='python2_7 python3_6'
PYTHON_SINGLE_TARGET='python3_6'

I see this is wrong but it raises two questions for me now...

1) How do I go about identifying in batch form which packages have been built with the existing PYTHON_SINGLE_TARGET_PYTHON3_6 and which now require PYTHON_SINGLE_TARGET_PYTHON2_7 setting in /etc/portage/package.use/* without individually running emerge -uDNa @world repeatedly until I'm no longer told REQUIRED_USE flag constraints are unsatisfied?

EDIT : Answered this myself, I can use...

Code: Select all

eix --installed-with-use python_single_target_python2_7

...but it doesn't currently return anything (as I've not adapted the USE flags yet). If I check...

Code: Select all

eix --installed-with-use python_targets_python2_7
 -c 
[I] app-admin/denyhosts (3.0-r1@09/06/19): DenyHosts is a utility to help sys admins thwart ssh hackers
[I] app-admin/syslog-ng (3.24.1@01/12/19): syslog replacement with advanced filtering features
[I] app-admin/webapp-config (1.55-r1@10/06/19): Gentoo's installer for web-based applications
[I] app-arch/brotli (1.0.7(0/1)@10/06/19): Generic-purpose lossless compression algorithm
[I] app-crypt/gpgme (1.13.1(1/11)@27/09/19): GnuPG Made Easy is a library for making GnuPG easier to use
[I] app-emulation/qemu (4.1.0@22/09/19): QEMU + Kernel-based Virtual Machine userland tools
[I] app-misc/pax-utils (1.2.4@05/08/19): ELF utils that can check files for security relevant properties
[I] app-misc/powerline [1] (2.7@10/06/19): Python-based statusline/prompt utility
[I] app-office/libreoffice (6.3.3.2@10/11/19): A full office productivity suite
[I] app-portage/gemato (14.3@19/11/19): Stand-alone Manifest generation & verification tool
...
[I] dev-python/virtualenv (16.7.8@06/12/19): Virtual Python Environment builder
[I] dev-python/virtualenv-clone (0.2.6@09/06/19): A script for cloning a non-relocatable virtualenv
[I] dev-python/virtualenvwrapper (4.8.4@11/08/19): Set of extensions to Ian Bicking's virtualenv tool
[I] dev-python/wcwidth (0.1.7-r2@17/11/19): Measures number of Terminal column cells of wide-character codes
[I] dev-python/webcolors (1.10@24/11/19): Color names and value formats defined by the HTML and CSS specifications
[1] "raiagent" /var/lib/layman/raiagent

Found 260 matches
Only 200 matches displayed on terminal
Set EIX_LIMIT_COMPACT=0 to show all matches

...there are 260 packages such packages, many of which are Python and are also built with 3.6 too...

Code: Select all

eix --installed-with-use python_targets_python3_6 -c 
[I] app-admin/denyhosts (3.0-r1@09/06/19): DenyHosts is a utility to help sys admins thwart ssh hackers
[I] app-admin/syslog-ng (3.24.1@01/12/19): syslog replacement with advanced filtering features
[I] app-admin/webapp-config (1.55-r1@10/06/19): Gentoo's installer for web-based applications
[I] app-arch/brotli (1.0.7(0/1)@10/06/19): Generic-purpose lossless compression algorithm
[I] app-crypt/gpgme (1.13.1(1/11)@27/09/19): GnuPG Made Easy is a library for making GnuPG easier to use
[U] app-editors/gedit (3.32.2@05/12/19 -> (~)3.32.2-r1): A text editor for the GNOME desktop
[I] app-emulation/qemu (4.1.0@22/09/19): QEMU + Kernel-based Virtual Machine userland tools
[I] app-eselect/eselect-repository (7@23/11/19): Manage repos.conf via eselect
...
[I] dev-python/rpy (2.9.0@10/06/19): Python interface to the R Programming Language
[I] dev-python/rsa (3.4.2@09/06/19): Pure-Python RSA implementation
[I] dev-python/scandir (1.10.0-r1@05/08/19): A better directory iterator and faster os.walk()
[I] dev-python/seaborn (0.9.0@10/06/19): Statistical data visualization
[I] dev-python/send2trash (1.5.0@09/06/19): Sends files to the Trash (or Recycle Bin)
[I] dev-python/service_identity (18.1.0@23/11/19): Service identity verification for pyOpenSSL
[I] dev-python/setuptools (42.0.2@02/12/19): Collection of extensions to Distutils
[1] "Personal overlay" /usr/local/portage
[2] "raiagent" /var/lib/layman/raiagent

Found 292 matches
Only 200 matches displayed on terminal
Set EIX_LIMIT_COMPACT=0 to show all matches

But how can I distinguish which have to have PYTHON_SINGLE_TARGET_PYTHON2_7 set?


2) Given Python 2.7 is due to reach the end of its supported life can anyone point me to the current plans to address this under Gentoo and Portage please?

EDIT : Found the above in is it safe to remove python:2.7? which I'll read in detail.

[fedeliallalinea]

2) Given Python 2.7 is due to reach the end of its supported life can anyone point me to the current plans to address this under Gentoo and Portage please?

viewtopic-t-1101210.html

[slackline]

I solved my issues by removing PYTHON_SINGLE_TARGET='python3_6' from /etc/portage/make.conf and then explicitly adding python_single_target_python3_6 for each package that was already installed with it (i.e. the output from eix --installed-with-use python_single_target_python3_6 -c).

[fedeliallalinea]

I solved my issues by removing PYTHON_SINGLE_TARGET='python3_6' from /etc/portage/make.conf and then explicitly adding python_single_target_python3_6 for each package that was already installed with it (i.e. the output from eix --installed-with-use python_single_target_python3_6 -c).

This configuration is provided by profile, theoretically you didn't have to add in package.use

[wjb]

I've been getting the problems since updating to sys-apps/portage-2.3.79 last night. This is a fairly new install (couple of months), there is nothing PYTHONish in make.conf, just in make.default.

I think the problem is a bit more than just python...

Looking at a current install that has use flags set by me and by the default

Code: Select all

# equery uses unison
[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for net-misc/unison-2.51.2:
 U I
 - - debug    : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful
                backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
 - - doc      : Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead
                of globally
 + + gtk      : Add support for x11-libs/gtk+ (The GIMP Toolkit)
 - + ocamlopt : Enable ocamlopt support (ocaml native code compiler) -- Produces faster programs (Warning:
                you have to disable/enable it at a global scale)
 - - static   : !!do not set this during bootstrap!! Causes binaries to be statically linked instead of
                dynamically
 - - test     : Enable dependencies and/or preparations necessary to run tests (usually controlled by
                FEATURES=test but can be toggled independently)
 - - threads  : Add threads support for various packages. Usually pthreads

- I've turned on gtk, and ocamlopt is coming from default (although there is a "-" on it in the user column)

Check how it was installed ...

Code: Select all

# eix ^unison$

[I] net-misc/unison
     Available versions:  
     (2.48) 2.48.4^s 2.48.4-r1^s
     (2.51) (~)2.51.2^s
       {debug doc gtk +ocamlopt static test threads}
     Installed versions:  2.51.2(2.51)(15:54:38 24/11/19)(gtk ocamlopt -debug -doc -static -test -threads)
     Homepage:            https://www.seas.upenn.edu/~bcpierce/unison/
     Description:         Two-way cross-platform file synchronizer

So - installed with gtk and ocamlopt

Reinstall

Code: Select all

jaguar wjb # emerge --quiet --quiet-build unison
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) net-misc/unison-2.51.2::gentoo
>>> Installing (1 of 1) net-misc/unison-2.51.2::gentoo

And now check to see how it installed

Code: Select all

jaguar wjb # eix ^$unison
[I] net-misc/unison
     Available versions:  
     (2.48) 2.48.4^s 2.48.4-r1^s
     (2.51) (~)2.51.2^s
       {debug doc gtk +ocamlopt static test threads}
     Installed versions:  2.51.2(2.51)^s(13:36:11 10/12/19)(gtk -debug -doc -ocamlopt -static -test -threads)
     Homepage:            https://www.seas.upenn.edu/~bcpierce/unison/
     Description:         Two-way cross-platform file synchronizer

Looks like ocamopt didn't make it! But the one I had explicitly set is fine.

Conclusion - the defaults are being disabled/overridden. Its just more noticeable with the python defaults.

[proteusx]

Here is my solution.

I got the python-single-r1.eclass version just before these stupid change from here and saved it in my local overlay (in my case: /usr/portage/local/eclass/)
Then I added this in my postsync script so as to overwrite the broken eclass :

Code: Select all

cp /usr/portage/local/eclass/python-single-r1.eclass /usr/portage/eclass/

PS. Our USE flags system used to be a paragon of elegance and the envy of the linux world. It seems that some of us are hell bent to make it into a monumental edifice of programming ineptitude. Just look at these python setting:

Code: Select all

# equery u gvim
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for app-editors/gvim-8.1.1846:
 U I
 + + acl                            : Add support for Access Control Lists
 - - cscope                         : Enable cscope interface
 - - debug                          : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
 - - gtk                            : Add support for x11-libs/gtk+ (The GIMP Toolkit)
 + + gtk2                           : Enable GTK+2 interface
 + + lua                            : Enable Lua scripting support
 - - luajit                         : Use dev-lang/luajit instead of dev-lang/lua (ineffective with USE=-lua)
 - - motif                          : Add support for the Motif toolkit
 - - neXt                           : Enable neXt toolkit
 - - netbeans                       : Include netbeans external editor integration support
 + + nls                            : Add Native Language Support (using gettext - GNU locale utilities)
 + + perl                           : Add optional support/bindings for the Perl language
 + + python                         : Add optional support/bindings for the Python language
 - - python_single_target_python2_7 : Build for Python 2.7 only
 - - python_single_target_python3_5 : Build for Python 3.5 only
 + + python_single_target_python3_6 : Build for Python 3.6 only
 - - python_single_target_python3_7 : Build for Python 3.7 only
 + + python_targets_python2_7       : Build with Python 2.7
 + + python_targets_python3_5       : Build with Python 3.5
 + + python_targets_python3_6       : Build with Python 3.6
 - - python_targets_python3_7       : Build with Python 3.7
 - - racket                         : Enable support for Scheme using dev-scheme/racket
 + + ruby                           : Add support/bindings for the Ruby language
 - - session                        : Add persistent session support
 - - sound                          : Enable sound support
 - - tcl                            : Add support the Tcl language

[asturm]

sigh.

and then explicitly adding python_single_target_python3_6 for each package that was already installed with it (i.e. the output from eix --installed-with-use python_single_target_python3_6 -c).

Why didn't you just read my link? package.use takes */* too. But as fedeliallalinea said, you don't have to set anything to go with the default.

[slackline]

and then explicitly adding python_single_target_python3_6 for each package that was already installed with it (i.e. the output from eix --installed-with-use python_single_target_python3_6 -c).

This configuration is provided by profile, theoretically you didn't have to add in package.use

Thanks thats useful to know.

[samuelbernardo]

If you have been setting PYTHON_TARGETS and PYTHON_SINGLE_TARGET inside /etc/portage/make.conf, you should move this to /etc/portage/package.use. This has been the recommendation for years.

https://wiki.gentoo.org/wiki/Project:Py ... ON_TARGETS

Hi asturm

Moving that into package.use doesn't seems to be so pretty as using make.conf. In my case I use package.use as a directory to organize my custom profile with the changes to the default profile.
Using make.conf allows to kept those main configurations in a format that allows to exchange my customizations more clearly.

Anyway, using package.use or make.conf the problem is the same since it asks for PYTHON_SINGLE_TARGET as python_2.7 and I already have set python 3 as it must be. It raises a conflict when for a package we select both for single target and so or we apply an hack using an eclass that overrides each ebuild that only use python 2.7 to force it as single target or we need to add explicitly to package.use each ebuild that relies on python 2.7.

To not rely on eclass that have been removed I think the best approach is to add to package.use all ebuilds that depends on python 2.7. The following oneliner allows to find every installed ebuild that have python 2.7 single target active and that should be appended to package.use:

Code: Select all

USE="python_single_target_python2_7"; for PKG in $(equery -q hasuse $USE); do echo $PKG: $(equery -q uses $PKG |grep $USE); done

I would be glad for any improvement or suggestions.

[EDIT]

It seems that equery hasuse doesn't list all installed ebuilds as expected...
Doing the following shows more ebuilds (this is not a good approach since I'm guessing lines before match that could miss or catch unexpected ebuild):

Code: Select all

eix -I | grep -B 5 'PYTHON_SINGLE_TARGET="+python2_7"' | grep "\[I\]"

Curiously that packages that are not listed with equery are the ones getting the python single target conflict.

[csteeves]

The reason the link provided above didn't help is that is says:

The modern packages (using -r1 suite eclasses) use explicit USE flags aggregated in PYTHON_TARGETS and PYTHON_SINGLE_TARGET USE_EXPAND variables. The variables are defaulted in profiles and can be changed in make.conf. The flags may be adjusted per-package using package.use as well.

What is wanted is a change to the default behaviour, not package-by-package modifications to the Python USE flags. The snippet above indicates that this should be done in make.conf.

However, this is the problem. Changes to the Python USE flags in make.conf appear to be causing the issues experienced by these users (why? I don't know). Removing or commenting the Python USE changes in make.conf appears to be a solution; see this thread viewtopic-t-1105134-highlight-python.html.

[WintermuteX]

If you have been setting PYTHON_TARGETS and PYTHON_SINGLE_TARGET inside /etc/portage/make.conf, you should move this to /etc/portage/package.use. This has been the recommendation for years.

https://wiki.gentoo.org/wiki/Project:Py ... ON_TARGETS

On the other hand you could admit what kind of a clusterfuck this is AGAIN.
I know, this might sound strange, BUT: many of us have installations since years. And many of us don't read any information given somewhere on the gentoo pages besides the notifications from emerge.
Many of us have lives going on and aren't looking for opportunities what to change next because someone decided to change something wracking havoc from one day to the next.
Thank you for your time. But I'm really pissed. This happens a lot in the near past.

[Ionen]

A solution is nice and all but yeah, this came out of nowhere and seem to have affected a lot of users on configurations (as pointed above) that been working for a long time. What was the reason for this change anyway? Was it intended?

Is there any reason at all to prevent the use of a single target when it's the _only possible_ target and exists in targets regardless of where it's set? The always-on automagic selection was just less strain on users.

Edit: If the change is necessary, it would help to inform users with a news item, especially since changes to eclasses affect stable systems without any real transition period (and the threads on this topic are starting to multiply).

[Ant P.]

On the other hand you could admit what kind of a clusterfuck this is AGAIN.
I know, this might sound strange, BUT: many of us have installations since years. And many of us don't read any information given somewhere on the gentoo pages besides the notifications from emerge.
Many of us have lives going on and aren't looking for opportunities what to change next because someone decided to change something wracking havoc from one day to the next.
Thank you for your time. But I'm really pissed. This happens a lot in the near past.

The package.use file, apart from being over a decade old, was mentioned in news items (those things with yellow asterisks that emerge urges you to read) as far back as 2014 and at least once a year after that. The PYTHON_TARGETS variable was first mentioned in a news item from 2012 shown to all users, and several times after that.

"Clusterfuck" and "havoc" may be apt words to describe the state of systems you admin, but it does not extend to Gentoo in general.

[TuxManager1337]

I have similar problems.

Since about 3-5 months, it is literally impossible to emerge -avuND1 @system @world for me.

Or anything linking to python, for that matter.

Any try to emerge of literally anything that has to do with python creates a dependency hell.

I will say that I have solved many of such dependency hells on Gentoo over the years, so I am used to it, but this is the first dependency hell that I am unable to solve.

The only solution I see is to exit X, unmerge half of the system and the re-emerge it again. But it is too time-consuming, it will be much faster to just install a new Gentoo from scratch...

Will anything be done about it?

I can donate a significant sum of money in cryptocurrency to a developer that fixes this permanently. I am just tired of this shit.

[saboya]

Most issues I've seen with python in the forums have to do with users setting PYTHON_TARGETS or PYTHON_SINGLE_TARGET in make.conf. Remove PYTHON_SINGLE_TARGET entirely and set a single PYTHON_TARGETS, if any (you don't have to).

Then emerge -uavDN @world. If you have anything that needs python 2.7 still, it will show up and you can add python_targets_python2_7 individually in /etc/portage/package.use. eselect python to set the correct versions and / or cleanup.

[proteusx]

Every time Gorny tinkers with the python-*-r1.eclasses, we cry.
I pays to keep a copy of the old versions handy.
In fact I keep my own overlay (I have named it pythoncrap) with the old eclasses and thus I keep myself out of trouble.

[Hu]

I will say that I have solved many of such dependency hells on Gentoo over the years, so I am used to it, but this is the first dependency hell that I am unable to solve.

The only solution I see is to exit X, unmerge half of the system and the re-emerge it again. But it is too time-consuming, it will be much faster to just install a new Gentoo from scratch...

Without access to the specific errors you are seeing, we cannot suggest a better course of action.

[TuxManager1337]

I will say that I have solved many of such dependency hells on Gentoo over the years, so I am used to it, but this is the first dependency hell that I am unable to solve.

The only solution I see is to exit X, unmerge half of the system and the re-emerge it again. But it is too time-consuming, it will be much faster to just install a new Gentoo from scratch...

Without access to the specific errors you are seeing, we cannot suggest a better course of action.

Very well.

My PYTHON_TARGETS:

Code: Select all

PYTHON_TARGETS="python3_6 python3_7"

Output from emerge -avuND1 @system @world:


https://pastebin.com/i1NY5cL7

Of course, addind these things to package.keywords and package.use won't work.



Here is output from just emerge -avu1 dev-python/setuptools dev-python/setuptools_scm dev-lang/python-exec:


https://pastebin.com/sY5kSw0U


Again, of course adding =dev-lang/python-exec-9999 ** to package keywords is not going to work at all.

Nothing is gonna happen, it will just fail again.