I would like to use only one Python3 version for all my packages in a Gentoo system. So I looked for the installed versions and found out that three versions are installed: 3.6, 3.7 and 3.8. I would like to convert all packages to 3.8 and delete the previous versions.

My plan:

  • Unmerge Python 3.6 and 3.7.
  • Set the USE flag for packages that use Python to python3_8 -python3_7 -python3_6.
  • Rebuild those packages with emerge --update --newuse to let them use Python 3.8.

So after removing Python 3.6 with:

emerge --ask -C dev-lang/python:3.6

I added the line

virtual/python-ipaddress python3_8 -python3_7 -python3_6

to /etc/portage/package.use and run

emerge --ask --update --newuse --deep virtual/python-ipaddress

and I get

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  NS    ] dev-lang/python-3.6.11-r2 [2.7.18-r1, 3.7.8-r2, 3.8.4-r1] USE="(threads%*)"

Would you like to merge these packages? [Yes/No]

I do not understand this behaviour: why does emerge want to install python-3.6 if /etc/portage/package.use specifies that it should use 3.8? And why does the USE variable not contain any Python specification? Is there another configuration file that has higher priority than /etc/portage/package.use and redefines the USE variable? From what I understand by reading the documentation, this should not happen.


BTW, python is not an ordinary package in Gentoo. (mostly because portage itself depends on python.) => Other variables are important to be set too. And need to be coherent. The idea behind USE flags is that it is reserved for setting user preferences. Preferences that can, at worse, make one package non functional but in no case, break the entire system.

The Python version is definitely NOT a user preference. NO! The user just cannot wake up and decide : I want Phython X.Y.Z only! Well... yes... the user can... At his own expenses.

In order to achieve your goal, (as I understand it), I would definitely not have proceeded the (highly risky *) way you followed.

I'd rather have followed the procedure detailed here under the paragraph Version Upgrade.

BTW : Also take care about the eselect thingy.

Not to say and out of interest... at the end of the day... why the hell would you want that ?

Tux ~ $ equery size python-2.7.18-r1
          Total files : 4177
          Total size  : 63.28 MiB
Tux ~ $ equery size python-3.7.8-r2
          Total files : 6616
          Total size  : 98.74 MiB

Recovering less than 200MB grand total to the potential expense of breaking misc interesting things ?

Pay attention! : You'll never actually convert, port a program from one language version to another one by fiddling use flags. You'll just link it to some different libraries which, if the program has not been made compatible with, will just break everything.

Highly risky (*) : I would never try unmergeing whatever package prior to the verification of the fact that no installed package strictly depends on it. I mean programs that have not been ported from python 2 to python 3 for instance. (I personally get a couple of those which definitely justify the existence of python-2.7.18-r1 on my systems)

Not to say that if you successfully removed 3.6 and 3.7, you almost certainly broke no less than the glib (2.62.6), wireshark, git... which latest stable versions, are, as far as a I can see, not yet 3.8 compatible...

Not to say that you could even have broken portage itself, forbidding any chance to recover from this apart thanks to backups that you... almost certainly... avoided to create....

  • Thanks for the information. I actually could also keep python-3.6 and remove python-3.7 and python-3.8. – Giorgio Aug 12 '20 at 12:10
  • What I am trying to achieve: I have managed to update the latest version of systemrescuecd and I would like to make a bootable cd. At the moment I get an image that's over 1 GB and I want to get it down to 700 MB. – Giorgio Aug 12 '20 at 12:11
  • The last official systemrescuecd only uses python-3.4 so I thought it should be possible to have all packages use one version of python 3. Another thing I am trying, is delete unused locales. – Giorgio Aug 12 '20 at 12:12
  • "which latest stable versions, are, as far as a I can see, not yet 3.8 compatible...": Shouldn't python-3.8 be backward compatible? I mean, maybe it is OK that they broke compatibility with python-2.*, but python-3.* versions should be backward compatible with each other, shouldn't they? – Giorgio Aug 12 '20 at 12:15
  • @Giorgio : Under Gentoo, I forgot everything about systemrescuecd since January 2018 : forums.gentoo.org/viewtopic-t-1092708-start-0.html . And at the end of the day, rescuing a Gentoo system does not go much farther than 1/ Having the machine booting on whatever 2/ having the capability to mount filesystems 3/ having the capability to setup appropriate network connection and finally to chroot into the more or less broken environment. Everything that the minimal installation CD (426MB to date) will be perfectly capable of. – MC68020 Aug 12 '20 at 13:08

When I am upgrading Python, here are the steps that I do (based partially on the Gentoo wiki):

  1. In /etc/portage/make.conf, add or update PYTHON_TARGETS and PYTHON_SINGLE_TARGET to the Python version that I want to use (e.g. PYTHON_TARGETS="python3_9 python3_8" and PYTHON_SINGLE_TARGET="python3_9") Note that the Gentoo wiki recommends doing this in package.use: either should work as this is a global change.

  2. Run emerge -puvDN --with-bdeps=y @world to verify that no packages are unhappy with the changes.

  3. Add or update the Python USE flags for individual packages.

I would strongly recommend against the use of emerge -C unless you are absolutely sure that no packages are using that package! Especially in the case of Python, you could make it so that emerge does not work at all.


As already noted in previous answers, it is not safe to remove package and then try to change the configuration to make it unneeded. The safe approach is the other way around - change your configuration (tuning USE flags, (un)masking versions) that the system itself recognize the package is not needed (this may need reinstall of few packages) and the system will remove it itself via emerge --depclean.

As for the original question, where python was forcibly removed, simply put --tree option to emerge update command. It will then list not only packages to be installed but also what brought them into the tree.

Most likely there is a package that still has dependency on python:3.6.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.