Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On Sat, 19 Dec 2020 11:20:26 +0100
n952162 wrote:
> /Is there a fundamental goals issue here, when there's so much
> incompatibility between python3_{6,7,8,9}? Do packages really need
> to care? Are these versions so fundamentally different from each
> other, and programmers rely on those differences? Or, is this
> somebody's orderliness tic?/
This bothers me too as a developer. I have created and maintain small
python program. The program itself requires almost no maintenance and
as far as I remember it has been compatible with any Python 3 version
since 3.2. The only thing that needs constant maintenance is the ebuild
where a list of exact Python versions have to be updated with each new
major Python release:
PYTHON_COMPAT=( python3_{6..9} )
It is not even possible to "outsmart" it with 'python3_{6..255}' or
something similar to be future proof.
I do not know the reasoning for such handling of Python in Gentoo.
Maybe I am oversimplifying it but I'd expect that specifying
dependencies to Python will be simple as any other. Something like:
RDEPEND=">=dev-lang/python:3"
Why this is not the standard and recommended way?
Robert
--
Róbert Čerňanský
E-mail: ope...@tightmail.com
Jabber: h...@jabber.sk
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
Neil Bothwick wrote: > On Sat, 19 Dec 2020 15:11:34 +0100, n952162 wrote: > > >> I update the /etc/portage/package.use files by hand, so I get a feeling >> for how it works. Can it be that etc-update is a "smart system" that >> does more than just that? > Yes, read the docs, it merges the old and new configs. I prefer to use > conf-update but all the config managers do much the same thing. > > There's also dispatch-conf as well. I can't recall how many config managers there is but each seems to work a little different. I'd suggest OP try them all and then pick the one they like the best. I like dispatch-conf but others like something else. Either of them gets the job done. Oh, some can also be configured to have fancy colors and such as well. Let's complicate things a little more. :/ Just another option, as if there wasn't already some mentioned. lol My opinion on the upgrade problem; I'd look at the world file, maybe even post it here, to see what has crept into it that shouldn't be there or is no longer in the tree. I had to unmerge several packages recently to get a update done. Some died ages ago. They were related to old python versions if I recall correctly. Dale :-) :-)
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On Sat, 19 Dec 2020 15:11:34 +0100, n952162 wrote:
> >> I don't think this output or any list participant has actually
> >> identified where the problem here is. In my original posting, the
> >> only difference causing the slot collision for jinja was that one
> >> had a PYTHON_TARGETS of 3-7 and the other of 3-8. I asked how to
> >> force it to the correct value, but if someone explained that to me,
> >> I didn't understand it.
> > You have specified manually a number of python versions, you
> > shouldn't have.
>
>
> Are you saying that long lists like this:
>
> *"python3_8 python3_9 (-pypy3) -python3_6 -python3_7*"
>
> are relics from improper or obsolete invocations made be me?
>
> If so, how can I get rid of them?
grep -ir python /etc/portage/package.use
You shouldn't really have many, if any, specific settings for
python_target. Comment out any you see and try again.
> > 2. Clean your world file from any and all dependencies, libraries and
> > packages you do not want to have explicitly installed.
>
>
> Yes, I receive that advice a lot. If I were to follow it aggressively,
> there would only be a handful of files in my world file. Will that
> work?
Absolutely. Remove anything you don't explicitly need then run depclean.
If something shows in the list that you want to keep, add it back with
emerge -n.
> I update the /etc/portage/package.use files by hand, so I get a feeling
> for how it works. Can it be that etc-update is a "smart system" that
> does more than just that?
Yes, read the docs, it merges the old and new configs. I prefer to use
conf-update but all the config managers do much the same thing.
> >> /Is there a fundamental goals issue here, when there's so much
> >> incompatibility between python3_{6,7,8,9}? Do packages really need
> >> to care? Are these versions so fundamentally different from each
> >> other, and programmers rely on those differences? Or, is this
> >> somebody's orderliness tic?/
It's also about where python modules are installed, but the main problem
here appears to be that you are depending on obsolete and deprecated
versions of python.
--
Neil Bothwick
What do you do when you see an endangered animal eating an endangered
plant?
pgpVYQWa3CyQu.pgp
Description: OpenPGP digital signature
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On Sat, 19 Dec 2020 15:19:22 +0100, n952162 wrote: > On 12/19/20 12:35 PM, Neil Bothwick wrote: > > On Sat, 19 Dec 2020 12:12:21 +0100, n952162 wrote: > > > >>> Your output gives away that you STILL have not run depclean, so you > >>> STILL have dev-python/ipaddress installed, which has been removed > >>> from the tree, and requires python 2.7. Unless you remove old broken > >>> software you will NEVER get through a world update. > >> > >> depclean output attached. > >> > >> >>> No packages selected for removal by depclean > >> Packages installed: 899 > >> Packages in world: 291 > >> Packages in system: 43 > >> Required packages: 899 > >> Number removed: 0 > > Which means the package is in @world, so just remove it with "emerge > > -cav ipaddress". > > $ sudo emerge -cav ipaddress 2>&1 | tee ipaddress-clean.$ymd > Password: > > Calculating dependencies done! > dev-python/ipaddress-1.0.23 pulled in by: > dev-python/cryptography-2.9 requires > dev-python/ipaddress[python_targets_python2_7(-),-python_single_target_python2_7(-)] > dev-python/urllib3-1.25.10 requires > dev-python/ipaddress[python_targets_python2_7(-),-python_single_target_python2_7(-)] > > >>> No packages selected for removal by depclean > Packages installed: 899 > Packages in world: 287 > Packages in system: 43 > Required packages: 899 > Number removed: 0 dev-python/cryptography-2.9 is no longer in the tree, it's an old python 2.7 package. Update it then you can remove ipaddress. -- Neil Bothwick Eye of newt, toe of frog, regular Coke and fries to go, please. pgpHS9DKVzLc5.pgp Description: OpenPGP digital signature
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On 12/19/20 12:35 PM, Neil Bothwick wrote: On Sat, 19 Dec 2020 12:12:21 +0100, n952162 wrote: Your output gives away that you STILL have not run depclean, so you STILL have dev-python/ipaddress installed, which has been removed from the tree, and requires python 2.7. Unless you remove old broken software you will NEVER get through a world update. depclean output attached. >>> No packages selected for removal by depclean Packages installed: 899 Packages in world: 291 Packages in system: 43 Required packages: 899 Number removed: 0 Which means the package is in @world, so just remove it with "emerge -cav ipaddress". Good. $ sudo emerge -cav ipaddress 2>&1 | tee ipaddress-clean.$ymd Password: Calculating dependencies done! dev-python/ipaddress-1.0.23 pulled in by: dev-python/cryptography-2.9 requires dev-python/ipaddress[python_targets_python2_7(-),-python_single_target_python2_7(-)] dev-python/urllib3-1.25.10 requires dev-python/ipaddress[python_targets_python2_7(-),-python_single_target_python2_7(-)] >>> No packages selected for removal by depclean Packages installed: 899 Packages in world: 287 Packages in system: 43 Required packages: 899 Number removed: 0
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On 12/19/20 12:35 PM, Michael wrote:
On Saturday, 19 December 2020 10:20:26 GMT n952162 wrote:
I don't think this output or any list participant has actually
identified where the problem here is. In my original posting, the only
difference causing the slot collision for jinja was that one had a
PYTHON_TARGETS of 3-7 and the other of 3-8. I asked how to force it to
the correct value, but if someone explained that to me, I didn't
understand it.
You have specified manually a number of python versions, you shouldn't have.
Are you saying that long lists like this:
*"python3_8 python3_9 (-pypy3) -python3_6 -python3_7*"
are relics from improper or obsolete invocations made be me?
If so, how can I get rid of them?
It seems you have also added permanently into your /var/lib/portage/world a
large number of dependencies and libraries due to your emerge syntax when
emerging specific packages, which again, you shouldn't have.
As a result with your own inputs in your portage configuration you are
fighting against what portage is trying to do in its calculations.
I would think the easiest solution would be to work with portage, rather than
despite portage:
1. Purge from your config files any hardcoded python targets, in order to let
portage choose which python target version it requires.
I have added or removed these definitions, either following suggestions
or attempting to provide prerequisites for packages that seem to require
them.
Absolutely, the best medicine is no medicine.
2. Clean your world file from any and all dependencies, libraries and packages
you do not want to have explicitly installed.
Yes, I receive that advice a lot. If I were to follow it aggressively,
there would only be a handful of files in my world file. Will that work?
3. If 'emerge -uaNDv @system' gives you similar errors as above, try emerging
one package at a time with '--oneshot', so it does not inadvertently end up in
your world; e.g.
emerge -1aNDv
I can't get *anything* to emerge, either alone, with near dependencies
(as in the orginal posting) or in sets.
Do not specify a package version in the above, just a name only. Let portage
install the version it calculates is appropriate and update any dependencies
needed.
I never do.
If your toolchain is completely borked, you could try the same by
using a Live-CD and a latest portage snapshot as per the guide book.
Is that much different than a re-install?
4. When you finish emerging @system you should have a sound toolchain to build
the rest of your Gentoo installation with. Run the following:
etc-update (to update your system configuration files)
emerge --depclean -v -a (to unmerge packages/versions no longer needed)
5. Follow with 'emerge -uaNDv @world'.
6. When you finish all this run:
etc-update
emerge -v -a @preserved-rebuild --keep-going
emerge --depclean -v -a
revdep-rebuild -v -- -a
/usr/bin/eclean-dist
7. Build the latest kernel, update grub's menu, reboot.
Yes, I perform these steps, basically, once I get an update emerge to work.
I update the /etc/portage/package.use files by hand, so I get a feeling
for how it works. Can it be that etc-update is a "smart system" that
does more than just that?
/Is there a fundamental goals issue here, when there's so much
incompatibility between python3_{6,7,8,9}? Do packages really need to
care? Are these versions so fundamentally different from each other,
and programmers rely on those differences? Or, is this somebody's
orderliness tic?/
Portage runs on python and it is also a dependency on a large number of other
packages and scripts. As python upstream is gradually deprecating older
versions, Gentoo has to follow through with the migration. The portage tree
is presently in a relative state of flux because of this, but it should soon
slow down again.
/What I'm wondering is if packages aren't specifying with too fine a
granularity./
If your system is borked for unknown reasons and following the above
suggestions you can't arrive at a stable state, perhaps it is time for you to
reinstall - which by the look of things it ought to take less of your time?
I was thinking I'd just re-installed this system but I guess that had
just been a painful @world update - I see that I installed it last
year. If I continue not being able to get a single emerge, I guess
that's how I'll have to go.
I'm surprised, though, that nobody could address the reduced case I
presented in the original posting:
- is the same package being re-installed with new python target
requirements, or am I interpreting it wrongly?
- is there no way to satisfy the differing python target requirements?
- are there consequences on other packages to emerging this package
that make it impossible?
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On Sat, 19 Dec 2020 at 12:11, n952162 wrote: > In the original posting of this thread, I presented a slot collision > where the only difference between the two packages was the > PYTHON_TARGET. I interpret that to mean that new dependencies want the > new python. Since the package is the same, it ought to be possible to > tell emerge(1) to assume a specific PYTHON_TARGET. Otherwise, there's no > way out of the dilemma. If setting the PYTHON_TARGET as I've done it is > not effective, do you know another way? Maybe we should go back to the slot collision you get now then, and try to explain how to read it, so maybe you can avoid these kinds of things in the future (you can probably avoid them just by getting through this, as it's been years since we've had such troublesome upgrades as the recent python upgrades). In an e-mail today, the FIRST errors after portage tells you what packages it wants to upgrade, you get this: dev-python/setuptools:0 (dev-python/setuptools-50.3.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 (-pypy3) -python3_6 -python3_7 -python3_9" pulled in by >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (dev-python/sphinxcontrib-devhelp-1.0.2:0/0::gentoo, ebuild scheduled for merge) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 (-pypy3) -python3_6 -python3_7 -python3_9" ... and many others that want to upgrade to the same ... (dev-python/setuptools-46.4.0-r3:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python2_7 python3_6 python3_7 (-pypy3) -python3_8 -python3_9" pulled in by >=dev-python/setuptools-1.0[python_targets_python2_7(-),python_targets_python3_6(-),python_targets_python3_7(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (dev-python/cryptography-2.9:0/0::gentoo, installed) USE="-idna -libressl -test" ABI_X86="(64)" PYTHON_TARGETS="python2_7 python3_6 python3_7 (-pypy3) -python3_8 -python3_9" ... and again others with the same problem ... So, most packages want to upgrade to the latest version, with PYTHON_TARGETS="python3_8". As far as I know, the top packages are those that the system wants to automatically upgrade normally. Then, the first package in the next list is dev-python/cryptopgraphy-2.9.0, which requires setuptools-46.4.0-r3, the last version which supports PYTHON_TARGETS="python2_7 python3_6 python3_7". If this was the latest version of cryptography, you might be stuck here for a while, maybe waiting for an update for cryptography, but it is not, a newer version is available. So why is portage not able to upgrade it? It tells you further down: dev-python/cryptography:0 (dev-python/cryptography-3.2.1:0/0::gentoo, ebuild scheduled for merge) USE="-idna -libressl -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 (-pypy3) -python3_6 -python3_7 -python3_9" pulled in by >=dev-python/cryptography-1.3.4[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (dev-python/requests-2.24.0-r1:0/0::gentoo, ebuild scheduled for merge) USE="ssl -socks5 -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 (-pypy3) -python3_6 -python3_7 -python3_9" ... and a few others ... (dev-python/cryptography-2.9:0/0::gentoo, installed) USE="-idna -libressl -test" ABI_X86="(64)" PYTHON_TARGETS="python2_7 python3_6 python3_7 (-pypy3) -python3_8 -python3_9" pulled in by >=dev-python/cryptography-2.8[python_targets_python2_7(-),python_targets_python3_6(-),python_targets_python3_7(-),-python_single_target_pypy3(-),-python_single_target_python2_7(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (dev-python/pyopenssl-19.1.0:0/0::gentoo, installed) USE="-doc -test" ABI_X86="(64)" PYTHON_TARGETS="python2_7 python3_6 python3_7 (-pypy3) -python3_8 -python3_9" So here we have the same problem with dev-python/pyopenssl-19.1.0, there is a newer version available, but portage can't upgrade it, so we need to move on to the next step once more. dev-python/pyopenssl:0 (dev-python/pyopenssl-19.1.0-r1:0/0::gentoo, ebuild scheduled for merge) USE="-doc -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 (-pypy3) -python3_6 -python3_7 -python3_9" pulled in
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
Python is every bit as much trouble in gentoo as it is in the Florida swamps. Python is so much trouble the History Channel has a Swamp People program they're showing regularly on TV. Could the post-install section of the handbook do with some good updates? On Sat, 19 Dec 2020, Michael wrote: > Date: Sat, 19 Dec 2020 06:51:18 > From: Michael > Reply-To: gentoo-user@lists.gentoo.org > To: gentoo-user@lists.gentoo.org > Subject: Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision > > On Saturday, 19 December 2020 11:37:31 GMT Neil Bothwick wrote: > > On Sat, 19 Dec 2020 12:33:10 +0100, n952162 wrote: > > > I do an emerge @world, it tells me I have slot collisions and stops. > > > Following Neil B.'s advice, I try to go through the collisions and see > > > what the differences are. jinja was a nice example, because there was a > > > collision of the same package with itself! The only difference was the > > > PYTHON_TARGET. I hoped someone could explain how I could force > > > equivalency in that simple case. > > > > You need to follow the trail back further. If portage wants to install > > two variants of jnja, look to see what is requiring them, that is most > > likely where the real solution lies. > > 'emerge --tree -uNDpv @system' or '@world', will also show the respective > dependency tree of any packages portage is trying to update. If an older > version of jinja is being dragged in by a non-system package, you can > temporarily uninstall that package and make a note of it to re-install it > later if you need/want to. --
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On Saturday, 19 December 2020 11:37:31 GMT Neil Bothwick wrote: > On Sat, 19 Dec 2020 12:33:10 +0100, n952162 wrote: > > I do an emerge @world, it tells me I have slot collisions and stops. > > Following Neil B.'s advice, I try to go through the collisions and see > > what the differences are. jinja was a nice example, because there was a > > collision of the same package with itself! The only difference was the > > PYTHON_TARGET. I hoped someone could explain how I could force > > equivalency in that simple case. > > You need to follow the trail back further. If portage wants to install > two variants of jnja, look to see what is requiring them, that is most > likely where the real solution lies. 'emerge --tree -uNDpv @system' or '@world', will also show the respective dependency tree of any packages portage is trying to update. If an older version of jinja is being dragged in by a non-system package, you can temporarily uninstall that package and make a note of it to re-install it later if you need/want to. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On Sat, 19 Dec 2020 12:33:10 +0100, n952162 wrote: > I do an emerge @world, it tells me I have slot collisions and stops. > Following Neil B.'s advice, I try to go through the collisions and see > what the differences are. jinja was a nice example, because there was a > collision of the same package with itself! The only difference was the > PYTHON_TARGET. I hoped someone could explain how I could force > equivalency in that simple case. You need to follow the trail back further. If portage wants to install two variants of jnja, look to see what is requiring them, that is most likely where the real solution lies. -- Neil Bothwick If Satan ever loses his hair, there'll be hell toupee. pgpG1gxZQsVOn.pgp Description: OpenPGP digital signature
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On Saturday, 19 December 2020 10:20:26 GMT n952162 wrote:
> I don't think this output or any list participant has actually
> identified where the problem here is. In my original posting, the only
> difference causing the slot collision for jinja was that one had a
> PYTHON_TARGETS of 3-7 and the other of 3-8. I asked how to force it to
> the correct value, but if someone explained that to me, I didn't
> understand it.
You have specified manually a number of python versions, you shouldn't have.
It seems you have also added permanently into your /var/lib/portage/world a
large number of dependencies and libraries due to your emerge syntax when
emerging specific packages, which again, you shouldn't have.
As a result with your own inputs in your portage configuration you are
fighting against what portage is trying to do in its calculations.
I would think the easiest solution would be to work with portage, rather than
despite portage:
1. Purge from your config files any hardcoded python targets, in order to let
portage choose which python target version it requires.
2. Clean your world file from any and all dependencies, libraries and packages
you do not want to have explicitly installed.
3. If 'emerge -uaNDv @system' gives you similar errors as above, try emerging
one package at a time with '--oneshot', so it does not inadvertently end up in
your world; e.g.
emerge -1aNDv
Do not specify a package version in the above, just a name only. Let portage
install the version it calculates is appropriate and update any dependencies
needed. If your toolchain is completely borked, you could try the same by
using a Live-CD and a latest portage snapshot as per the guide book.
4. When you finish emerging @system you should have a sound toolchain to build
the rest of your Gentoo installation with. Run the following:
etc-update (to update your system configuration files)
emerge --depclean -v -a (to unmerge packages/versions no longer needed)
5. Follow with 'emerge -uaNDv @world'.
6. When you finish all this run:
etc-update
emerge -v -a @preserved-rebuild --keep-going
emerge --depclean -v -a
revdep-rebuild -v -- -a
/usr/bin/eclean-dist
7. Build the latest kernel, update grub's menu, reboot.
> I'm afraid I'm going to have to give up on gentoo, although I'm pretty
> heavily invested in it. I'm spending too many hours trying to maintain
> my systems and running into too many seemingly arbitrary roadblocks.
> I'm told I should update every week, but I can't get a system updated in
> a week.
I have some systems I update once a month or even less frequently. There's an
old box I use sometimes for testing. I don't update this particular box for
the best part of 3 months at a time. I very rarely, if ever, arrive at hard
[B]locks and even when I do I often resolve them by changing or reverting to
defaults their USE flags, or first using quickpkg, then manually unmerging the
blocking non-system package and letting portage decide for me what package
version to emerge and which dependencies it needs.
YMMV, but a stable system should not be too troublesome to update if you
follow the above advice.
This mailing list, forums and IRC channels tend to offer really good advice,
in case you want to try a different crowd for ideas.
HTH. :-)
> /Is there a fundamental goals issue here, when there's so much
> incompatibility between python3_{6,7,8,9}? Do packages really need to
> care? Are these versions so fundamentally different from each other,
> and programmers rely on those differences? Or, is this somebody's
> orderliness tic?/
Portage runs on python and it is also a dependency on a large number of other
packages and scripts. As python upstream is gradually deprecating older
versions, Gentoo has to follow through with the migration. The portage tree
is presently in a relative state of flux because of this, but it should soon
slow down again.
If your system is borked for unknown reasons and following the above
suggestions you can't arrive at a stable state, perhaps it is time for you to
reinstall - which by the look of things it ought to take less of your time?
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On Sat, 19 Dec 2020 12:12:21 +0100, n952162 wrote: > > Your output gives away that you STILL have not run depclean, so you > > STILL have dev-python/ipaddress installed, which has been removed from > > the tree, and requires python 2.7. Unless you remove old broken > > software you will NEVER get through a world update. > > > depclean output attached. > > >>> No packages selected for removal by depclean > Packages installed: 899 > Packages in world: 291 > Packages in system: 43 > Required packages: 899 > Number removed: 0 Which means the package is in @world, so just remove it with "emerge -cav ipaddress". -- Neil Bothwick You can't teach a new mouse old clicks. pgpW1dq3PZI5h.pgp Description: OpenPGP digital signature
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On 12/19/20 12:12 PM, bobwxc wrote:
在 2020/12/19 下午6:20, n952162 写道:
On 12/16/20 11:59 AM, Arve Barsnes wrote:
On Wed, 16 Dec 2020 at 11:34, Miles Malone
wrote:
What's happening when you do emerge -avuDN --with-bdeps=y
--backtrack=100 @world ? Giving portage the flexibility to solve it
with some extra backtracking and increasing the scope to world might
fix it, if not then we can revisit it?
You should definitely try this first if you haven't.
I have.
If the package was good enough before, it's likely still good enough. Where's
the problem? I've (unsuccessfully) made these attempts:
# */* PYTHON_TARGETS: python3_6 python3_7 python3_8 python3_9
#*/* PYTHON_TARGETS: -python3_6 -python3_7 python3_8 python3_9
# just have one set
*/* PYTHON_TARGETS: python3_8
Is there any reason that you need to add py3.9 to all packages? If you
need it for something special, add it to those packages only, and let
portage take care of python targets for you instead of continuously
trying these big hammers. Ideally you should have *no* python targets
set manually in make.conf or USE files.
I added it because I saw python3_9 in the PYTHON_TARGETS list for,
e.g. jinja, and hoped that it would force compatibility. That is the
question of the original post. But that was just one of many attempts.
The emerge command was:
sudo emerge --verbose=y -vuUD --verbose-conflicts dev-python/setuptools
dev-python/setuptools_scm dev-python/certifi dev-python/markupsafe
dev-python/jinja dev-libs/libxml2
Since it seems sphinx is installed with a different set of python
targets than what you're trying to update, you should include sphinx
in that emerge command to let it update to the same python targets and
solve the conflict.
Regards,
Arve
I tried adding that but it didn't help.
My latest command was:
time emerge \
-v \
--deep \
--update \
--changed-use \
--verbose-conflicts \
--keep-going \
--with-bdeps=y \
--changed-deps \
--backtrack=100 \
--newuse \
dev-python/setuptools dev-python/setuptools_scm dev-python/certifi
dev-python/markupsafe dev-python/jinja dev-libs/libxml2 dev-python/sphinx
Below is the latest build output, with no PYTHON_TARGET specifications.
...
real 0m45.063s
user 0m44.602s
sys 0m0.399s
I don't think this output or any list participant has actually
identified where the problem here is. In my original posting, the
only difference causing the slot collision for jinja was that one had
a PYTHON_TARGETS of 3-7 and the other of 3-8. I asked how to force
it to the correct value, but if someone explained that to me, I
didn't understand it.
I'm afraid I'm going to have to give up on gentoo, although I'm
pretty heavily invested in it. I'm spending too many hours trying to
maintain my systems and running into too many seemingly arbitrary
roadblocks. I'm told I should update every week, but I can't get a
system updated in a week.
/Is there a fundamental goals issue here, when there's so much
incompatibility between python3_{6,7,8,9}? Do packages really need
to care? Are these versions so fundamentally different from each
other, and programmers rely on those differences? Or, is this
somebody's orderliness tic?/
So what do you really want to know?
Well, for starters, why emerge(1) is not emerging...
Using jinja with python3.6 3.7.3.8 3.9 at the same time?
I don't know what jinja is and I just switched over to python3 myself.
I'm not into subtleties like 6, 7, 8, or 9.
I do an emerge @world, it tells me I have slot collisions and stops.
Following Neil B.'s advice, I try to go through the collisions and see
what the differences are. jinja was a nice example, because there was a
collision of the same package with itself! The only difference was the
PYTHON_TARGET. I hoped someone could explain how I could force
equivalency in that simple case.
Or want to keep it with 3.6 or some else?
The default PYTHON_TARGETS now change to 3_8 from 3_6. So when you
update, many software need to change.
Yeah. That surprises me, actually.
If you want to change that targets, just follow
https://wiki.gentoo.org/wiki/Project:Python/PYTHON_TARGETS
Maybe there no different or compatibility with it actually, but we
need a correct dependency.
I'm trying to emerge. I'm not developing anything.
If you do not have enough time to update and config gentoo,
maybe you should try other Linux like Arch(No need to compile) and
Debian(less update).
Yes, that's always an option. On the other hand, it might be possible
to improve gentoo so that not only the very brightest people can use
it. Source is kind of like a vaccine - if enough people use it, it can
help prevent the spread of viruses.
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On 12/19/20 11:45 AM, William Kenworthy wrote: Backtracking rarely helps in my experience. check the blocks: using --nodeps forces the install, then it may work (you may have to add to package.accept_keywords etc. to cover that angle - but I am on arm and arm64 where the most difficult of the python problems happened for me) I also have: USE_PYTHON="3.8" PYTHON_TARGETS="python3_8" PYTHON_SINGLE_TARGET="python3_8" *** a number of packages from overlays I am using don't like 3.9 so I removed it) I have a number of intel, arm and arm64 and virtualised systems and all have problems with python in some way or other - I could only remove the python targets on a couple of them. After a mass update, I have been trying to remove the targets but its only working for a few so far, and they are not stable. Thank you, I'll try. I wish python would just go away and perl gets brought back - a lot less drama ... :-) ah yeah ...
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
在 2020/12/19 下午6:20, n952162 写道:
On 12/16/20 11:59 AM, Arve Barsnes wrote:
On Wed, 16 Dec 2020 at 11:34, Miles Malone
wrote:
What's happening when you do emerge -avuDN --with-bdeps=y
--backtrack=100 @world ? Giving portage the flexibility to solve it
with some extra backtracking and increasing the scope to world might
fix it, if not then we can revisit it?
You should definitely try this first if you haven't.
I have.
If the package was good enough before, it's likely still good enough. Where's
the problem? I've (unsuccessfully) made these attempts:
# */* PYTHON_TARGETS: python3_6 python3_7 python3_8 python3_9
#*/* PYTHON_TARGETS: -python3_6 -python3_7 python3_8 python3_9
# just have one set
*/* PYTHON_TARGETS: python3_8
Is there any reason that you need to add py3.9 to all packages? If you
need it for something special, add it to those packages only, and let
portage take care of python targets for you instead of continuously
trying these big hammers. Ideally you should have *no* python targets
set manually in make.conf or USE files.
I added it because I saw python3_9 in the PYTHON_TARGETS list for,
e.g. jinja, and hoped that it would force compatibility. That is the
question of the original post. But that was just one of many attempts.
The emerge command was:
sudo emerge --verbose=y -vuUD --verbose-conflicts dev-python/setuptools
dev-python/setuptools_scm dev-python/certifi dev-python/markupsafe
dev-python/jinja dev-libs/libxml2
Since it seems sphinx is installed with a different set of python
targets than what you're trying to update, you should include sphinx
in that emerge command to let it update to the same python targets and
solve the conflict.
Regards,
Arve
I tried adding that but it didn't help.
My latest command was:
time emerge \
-v \
--deep \
--update \
--changed-use \
--verbose-conflicts \
--keep-going \
--with-bdeps=y \
--changed-deps \
--backtrack=100 \
--newuse \
dev-python/setuptools dev-python/setuptools_scm dev-python/certifi
dev-python/markupsafe dev-python/jinja dev-libs/libxml2 dev-python/sphinx
Below is the latest build output, with no PYTHON_TARGET specifications.
...
real 0m45.063s
user 0m44.602s
sys 0m0.399s
I don't think this output or any list participant has actually
identified where the problem here is. In my original posting, the
only difference causing the slot collision for jinja was that one had
a PYTHON_TARGETS of 3-7 and the other of 3-8. I asked how to force it
to the correct value, but if someone explained that to me, I didn't
understand it.
I'm afraid I'm going to have to give up on gentoo, although I'm pretty
heavily invested in it. I'm spending too many hours trying to
maintain my systems and running into too many seemingly arbitrary
roadblocks. I'm told I should update every week, but I can't get a
system updated in a week.
/Is there a fundamental goals issue here, when there's so much
incompatibility between python3_{6,7,8,9}? Do packages really need
to care? Are these versions so fundamentally different from each
other, and programmers rely on those differences? Or, is this
somebody's orderliness tic?/
So what do you really want to know?
Using jinja with python3.6 3.7.3.8 3.9 at the same time?
Or want to keep it with 3.6 or some else?
The default PYTHON_TARGETS now change to 3_8 from 3_6. So when you
update, many software need to change.
If you want to change that targets, just follow
https://wiki.gentoo.org/wiki/Project:Python/PYTHON_TARGETS
Maybe there no different or compatibility with it actually, but we need
a correct dependency.
If you do not have enough time to update and config gentoo,
maybe you should try other Linux like Arch(No need to compile) and
Debian(less update).
:-)
--
bobwxc
OpenPGP_0x36E94EABB53E516B.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On Sat, 19 Dec 2020 at 11:19, n952162 wrote: > I don't think this output or any list participant has actually identified > where the problem here is. In my original posting, the only difference > causing the slot collision for jinja was that one had a PYTHON_TARGETS of 3-7 > and the other of 3-8. I asked how to force it to the correct value, but if > someone explained that to me, I didn't understand it. Your output gives away that you STILL have not run depclean, so you STILL have dev-python/ipaddress installed, which has been removed from the tree, and requires python 2.7. Unless you remove old broken software you will NEVER get through a world update. Also: don't set PYTHON_TARGETS unless you have a REALLY good reason. You can set it on a specific package (and preferrable to set it only on a specific version of that package) to go around problems, but DON'T do this until you have made your system sane (meaning you can run world updates without troubles). Regards, Arve
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On 19/12/20 6:20 pm, n952162 wrote: > On 12/16/20 11:59 AM, Arve Barsnes wrote: >> On Wed, 16 Dec 2020 at 11:34, Miles Malone >> wrote: >>> What's happening when you do emerge -avuDN --with-bdeps=y >>> --backtrack=100 @world ? Giving portage the flexibility to solve it >>> with some extra backtracking and increasing the scope to world might >>> fix it, if not then we can revisit it? >> You should definitely try this first if you haven't. > > > I have. > > ... Backtracking rarely helps in my experience. check the blocks: using --nodeps forces the install, then it may work (you may have to add to package.accept_keywords etc. to cover that angle - but I am on arm and arm64 where the most difficult of the python problems happened for me) I also have: USE_PYTHON="3.8" PYTHON_TARGETS="python3_8" PYTHON_SINGLE_TARGET="python3_8" *** a number of packages from overlays I am using don't like 3.9 so I removed it) I have a number of intel, arm and arm64 and virtualised systems and all have problems with python in some way or other - I could only remove the python targets on a couple of them. After a mass update, I have been trying to remove the targets but its only working for a few so far, and they are not stable. I wish python would just go away and perl gets brought back - a lot less drama ... BillK
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On 12/16/20 11:34 AM, Miles Malone wrote: What's happening when you do emerge -avuDN --with-bdeps=y --backtrack=100 @world ? Giving portage the flexibility to solve it with some extra backtracking and increasing the scope to world might fix it, if not then we can revisit it? That's how I started this process. That failed, and I tried cutting back the scope of the emerge, but it hasn't helped.
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
Miles Malone wrote: > Personally I just like to see what I'm getting myself into before I > start doing an upgrade or recompile on all of chromium, firefox, > qt-webkit, gtk-webkit, qt-webengine, libreoffice, and electron all at > once :p > To quote the meme, this little manouver's going to take us 51 years > > That's true for me too. I sometimes do my updates in a chroot and then install binaries on my main install when it is done. It's also a good idea to check the USE flag changes as well. Sometimes a new USE flag is added or one that used to default to enabled is now defaulting to disabled or vice versa. If you see the change, it gives you a chance to edit the correct config file to get the result you want. Before -a came along, everyone did a -p which meant removing the -p and running again to do a update. The -a gives you a chance to look and then proceed if all looks right without having to run emerge again. Sometimes it can take a while for emerge to process what gets done. It's rare, very rare, that I run a emerge command without -a. I always check what will be done first. Dale :-) :-)
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
Personally I just like to see what I'm getting myself into before I
start doing an upgrade or recompile on all of chromium, firefox,
qt-webkit, gtk-webkit, qt-webengine, libreoffice, and electron all at
once :p
To quote the meme, this little manouver's going to take us 51 years
On Wed, 16 Dec 2020 at 21:06, n952162 wrote:
>
> On 12/16/20 11:34 AM, Miles Malone wrote:
> > What's happening when you do emerge -avuDN --with-bdeps=y
> > --backtrack=100 @world ? Giving portage the flexibility to solve it
> > with some extra backtracking and increasing the scope to world might
> > fix it, if not then we can revisit it?
>
>
> I don't remember if I've tried that combination, I'll do so now.
>
>
> ... you include -a. Under what situation might I respond to the prompt
> with 'no'?
>
>
>
> >
> > On Wed, 16 Dec 2020 at 20:24, n952162 wrote:
> >> In an update with several slot collisions (see attachment), I'm zero-ing
> >> in on the simplest, where a package is to be replaced by the same package,
> >> but with different PYTHON_TARGETS (at least, that's how I interpret it).
> >>
> >> Is there a way to force the PYTHON_TARGETS of the dependency?
> >>
> >> Slot collision:
> >>
> >> dev-python/jinja:0
> >>
> >>(dev-python/jinja-2.11.2-r1:0/0::gentoo, ebuild scheduled for merge)
> >> USE="-doc -examples -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8
> >> python3_9 (-pypy3) -python3_6 -python3_7" pulled in by
> >>
> >> dev-python/jinja[python_targets_python3_9(-),python_single_target_python3_9(+)]
> >> required by (sys-auth/pambase-20201103:0/0::gentoo, ebuild scheduled for
> >> merge) USE="nullok passwdqc sha512 -caps -debug -elogind -gnome-keyring
> >> -minimal -mktemp -pam_krb5 -pam_ssh -pwhistory -pwquality -securetty
> >> (-selinux) -systemd" ABI_X86="(64)"
> >>
> >>
> >> dev-python/jinja (Argument)
> >>
> >>(dev-python/jinja-2.11.2-r1:0/0::gentoo, installed) USE="-doc -examples
> >> -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6
> >> -python3_8 -python3_9" pulled in by
> >>
> >> dev-python/jinja[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
> >> required by (dev-python/sphinx-3.2.1:0/0::gentoo, installed) USE="-doc
> >> -latex -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6
> >> -python3_8 -python3_9"
> >>
> >> If the package was good enough before, it's likely still good enough.
> >> Where's the problem? I've (unsuccessfully) made these attempts:
> >>
> >> # */* PYTHON_TARGETS: python3_6 python3_7 python3_8 python3_9
> >> #*/* PYTHON_TARGETS: -python3_6 -python3_7 python3_8 python3_9
> >> # just have one set
> >> */* PYTHON_TARGETS: python3_8
> >>
> >> The sphinx ebuild has no targets, but does have this:
> >>
> >> PYTHON_COMPAT=( python3_{6..9} pypy3 )
> >>
> >> The emerge command was:
> >>
> >> sudo emerge --verbose=y -vuUD --verbose-conflicts
> >> dev-python/setuptools dev-python/setuptools_scm dev-python/certifi
> >> dev-python/markupsafe dev-python/jinja dev-libs/libxml2
> >>
> >>
>
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
If it's wanting to downgrade something you definitely wouldnt want
downgraded is one, but feel free to omit the "a" and do the above
anyway
On Wed, 16 Dec 2020 at 21:06, n952162 wrote:
>
> On 12/16/20 11:34 AM, Miles Malone wrote:
> > What's happening when you do emerge -avuDN --with-bdeps=y
> > --backtrack=100 @world ? Giving portage the flexibility to solve it
> > with some extra backtracking and increasing the scope to world might
> > fix it, if not then we can revisit it?
>
>
> I don't remember if I've tried that combination, I'll do so now.
>
>
> ... you include -a. Under what situation might I respond to the prompt
> with 'no'?
>
>
>
> >
> > On Wed, 16 Dec 2020 at 20:24, n952162 wrote:
> >> In an update with several slot collisions (see attachment), I'm zero-ing
> >> in on the simplest, where a package is to be replaced by the same package,
> >> but with different PYTHON_TARGETS (at least, that's how I interpret it).
> >>
> >> Is there a way to force the PYTHON_TARGETS of the dependency?
> >>
> >> Slot collision:
> >>
> >> dev-python/jinja:0
> >>
> >>(dev-python/jinja-2.11.2-r1:0/0::gentoo, ebuild scheduled for merge)
> >> USE="-doc -examples -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8
> >> python3_9 (-pypy3) -python3_6 -python3_7" pulled in by
> >>
> >> dev-python/jinja[python_targets_python3_9(-),python_single_target_python3_9(+)]
> >> required by (sys-auth/pambase-20201103:0/0::gentoo, ebuild scheduled for
> >> merge) USE="nullok passwdqc sha512 -caps -debug -elogind -gnome-keyring
> >> -minimal -mktemp -pam_krb5 -pam_ssh -pwhistory -pwquality -securetty
> >> (-selinux) -systemd" ABI_X86="(64)"
> >>
> >>
> >> dev-python/jinja (Argument)
> >>
> >>(dev-python/jinja-2.11.2-r1:0/0::gentoo, installed) USE="-doc -examples
> >> -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6
> >> -python3_8 -python3_9" pulled in by
> >>
> >> dev-python/jinja[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
> >> required by (dev-python/sphinx-3.2.1:0/0::gentoo, installed) USE="-doc
> >> -latex -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6
> >> -python3_8 -python3_9"
> >>
> >> If the package was good enough before, it's likely still good enough.
> >> Where's the problem? I've (unsuccessfully) made these attempts:
> >>
> >> # */* PYTHON_TARGETS: python3_6 python3_7 python3_8 python3_9
> >> #*/* PYTHON_TARGETS: -python3_6 -python3_7 python3_8 python3_9
> >> # just have one set
> >> */* PYTHON_TARGETS: python3_8
> >>
> >> The sphinx ebuild has no targets, but does have this:
> >>
> >> PYTHON_COMPAT=( python3_{6..9} pypy3 )
> >>
> >> The emerge command was:
> >>
> >> sudo emerge --verbose=y -vuUD --verbose-conflicts
> >> dev-python/setuptools dev-python/setuptools_scm dev-python/certifi
> >> dev-python/markupsafe dev-python/jinja dev-libs/libxml2
> >>
> >>
>
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On 12/16/20 11:34 AM, Miles Malone wrote:
What's happening when you do emerge -avuDN --with-bdeps=y
--backtrack=100 @world ? Giving portage the flexibility to solve it
with some extra backtracking and increasing the scope to world might
fix it, if not then we can revisit it?
I don't remember if I've tried that combination, I'll do so now.
... you include -a. Under what situation might I respond to the prompt
with 'no'?
On Wed, 16 Dec 2020 at 20:24, n952162 wrote:
In an update with several slot collisions (see attachment), I'm zero-ing in on
the simplest, where a package is to be replaced by the same package, but with
different PYTHON_TARGETS (at least, that's how I interpret it).
Is there a way to force the PYTHON_TARGETS of the dependency?
Slot collision:
dev-python/jinja:0
(dev-python/jinja-2.11.2-r1:0/0::gentoo, ebuild scheduled for merge) USE="-doc -examples -test"
ABI_X86="(64)" PYTHON_TARGETS="python3_8 python3_9 (-pypy3) -python3_6 -python3_7" pulled
in by
dev-python/jinja[python_targets_python3_9(-),python_single_target_python3_9(+)] required by
(sys-auth/pambase-20201103:0/0::gentoo, ebuild scheduled for merge) USE="nullok passwdqc
sha512 -caps -debug -elogind -gnome-keyring -minimal -mktemp -pam_krb5 -pam_ssh -pwhistory
-pwquality -securetty (-selinux) -systemd" ABI_X86="(64)"
dev-python/jinja (Argument)
(dev-python/jinja-2.11.2-r1:0/0::gentoo, installed) USE="-doc -examples -test"
ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8 -python3_9"
pulled in by
dev-python/jinja[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
required by (dev-python/sphinx-3.2.1:0/0::gentoo, installed) USE="-doc -latex -test"
ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8 -python3_9"
If the package was good enough before, it's likely still good enough. Where's
the problem? I've (unsuccessfully) made these attempts:
# */* PYTHON_TARGETS: python3_6 python3_7 python3_8 python3_9
#*/* PYTHON_TARGETS: -python3_6 -python3_7 python3_8 python3_9
# just have one set
*/* PYTHON_TARGETS: python3_8
The sphinx ebuild has no targets, but does have this:
PYTHON_COMPAT=( python3_{6..9} pypy3 )
The emerge command was:
sudo emerge --verbose=y -vuUD --verbose-conflicts dev-python/setuptools
dev-python/setuptools_scm dev-python/certifi dev-python/markupsafe
dev-python/jinja dev-libs/libxml2
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
On Wed, 16 Dec 2020 at 11:34, Miles Malone wrote: > What's happening when you do emerge -avuDN --with-bdeps=y > --backtrack=100 @world ? Giving portage the flexibility to solve it > with some extra backtracking and increasing the scope to world might > fix it, if not then we can revisit it? You should definitely try this first if you haven't. > > If the package was good enough before, it's likely still good enough. > > Where's the problem? I've (unsuccessfully) made these attempts: > > > > # */* PYTHON_TARGETS: python3_6 python3_7 python3_8 python3_9 > > #*/* PYTHON_TARGETS: -python3_6 -python3_7 python3_8 python3_9 > > # just have one set > > */* PYTHON_TARGETS: python3_8 Is there any reason that you need to add py3.9 to all packages? If you need it for something special, add it to those packages only, and let portage take care of python targets for you instead of continuously trying these big hammers. Ideally you should have *no* python targets set manually in make.conf or USE files. > > The emerge command was: > > > > sudo emerge --verbose=y -vuUD --verbose-conflicts dev-python/setuptools > > dev-python/setuptools_scm dev-python/certifi dev-python/markupsafe > > dev-python/jinja dev-libs/libxml2 Since it seems sphinx is installed with a different set of python targets than what you're trying to update, you should include sphinx in that emerge command to let it update to the same python targets and solve the conflict. Regards, Arve
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
在 2020/12/16 下午6:24, n952162 写道:
In an update with several slot collisions (see attachment), I'm
zero-ing in on the simplest, where a package is to be replaced by the
same package, but with different PYTHON_TARGETS (at least, that's how
I interpret it).
Is there a way to force the PYTHON_TARGETS of the dependency?
Slot collision:
dev-python/jinja:0
(dev-python/jinja-2.11.2-r1:0/0::gentoo, ebuild scheduled for merge)
USE="-doc -examples -test" ABI_X86="(64)" PYTHON_TARGETS="*python3_8
python3_9 (-pypy3) -python3_6 -python3_7*" pulled in by
dev-python/jinja[python_targets_python3_9(-),python_single_target_python3_9(+)]
required by (sys-auth/pambase-20201103:0/0::gentoo, ebuild scheduled
for merge) USE="nullok passwdqc sha512 -caps -debug -elogind
-gnome-keyring -minimal -mktemp -pam_krb5 -pam_ssh -pwhistory
-pwquality -securetty (-selinux) -systemd" ABI_X86="(64)"
dev-python/jinja (Argument)
(dev-python/jinja-2.11.2-r1:0/0::gentoo, installed) USE="-doc
-examples -test" ABI_X86="(64)" PYTHON_TARGETS="*python3_7 (-pypy3)
-python3_6 -python3_8 -python3_9*" pulled in by
dev-python/jinja[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
required by (dev-python/sphinx-3.2.1:0/0::gentoo, installed) USE="-doc
-latex -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3)
-python3_6 -python3_8 -python3_9"
If the package was good enough before, it's likely still good enough.
Where's the problem? I've (unsuccessfully) made these attempts:
# */* PYTHON_TARGETS: python3_6 python3_7 python3_8 python3_9
#*/* PYTHON_TARGETS: -python3_6 -python3_7 python3_8 python3_9
# just have one set
*/* PYTHON_TARGETS: python3_8
The sphinx ebuild has no targets, but does have this:
PYTHON_COMPAT=( python3_{6..9} pypy3 )
The emerge command was:
sudo emerge --verbose=y -vuUD --verbose-conflicts
dev-python/setuptools dev-python/setuptools_scm dev-python/certifi
dev-python/markupsafe dev-python/jinja dev-libs/libxml2
According to the
https://wiki.gentoo.org/wiki/Project:Python/PYTHON_TARGETS and your log
may be set like
# Replacing the profile default with specific implementation
dev-python/* PYTHON_SINGLE_TARGET: python3_6
That will let all the dev-python target set to python3_6
--
bobwxc
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision
What's happening when you do emerge -avuDN --with-bdeps=y
--backtrack=100 @world ? Giving portage the flexibility to solve it
with some extra backtracking and increasing the scope to world might
fix it, if not then we can revisit it?
On Wed, 16 Dec 2020 at 20:24, n952162 wrote:
>
> In an update with several slot collisions (see attachment), I'm zero-ing in
> on the simplest, where a package is to be replaced by the same package, but
> with different PYTHON_TARGETS (at least, that's how I interpret it).
>
> Is there a way to force the PYTHON_TARGETS of the dependency?
>
> Slot collision:
>
> dev-python/jinja:0
>
> (dev-python/jinja-2.11.2-r1:0/0::gentoo, ebuild scheduled for merge)
> USE="-doc -examples -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 python3_9
> (-pypy3) -python3_6 -python3_7" pulled in by
>
> dev-python/jinja[python_targets_python3_9(-),python_single_target_python3_9(+)]
> required by (sys-auth/pambase-20201103:0/0::gentoo, ebuild scheduled for
> merge) USE="nullok passwdqc sha512 -caps -debug -elogind -gnome-keyring
> -minimal -mktemp -pam_krb5 -pam_ssh -pwhistory -pwquality -securetty
> (-selinux) -systemd" ABI_X86="(64)"
>
>
> dev-python/jinja (Argument)
>
> (dev-python/jinja-2.11.2-r1:0/0::gentoo, installed) USE="-doc -examples
> -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6
> -python3_8 -python3_9" pulled in by
>
> dev-python/jinja[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
> required by (dev-python/sphinx-3.2.1:0/0::gentoo, installed) USE="-doc
> -latex -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6
> -python3_8 -python3_9"
>
> If the package was good enough before, it's likely still good enough.
> Where's the problem? I've (unsuccessfully) made these attempts:
>
> # */* PYTHON_TARGETS: python3_6 python3_7 python3_8 python3_9
> #*/* PYTHON_TARGETS: -python3_6 -python3_7 python3_8 python3_9
> # just have one set
> */* PYTHON_TARGETS: python3_8
>
> The sphinx ebuild has no targets, but does have this:
>
> PYTHON_COMPAT=( python3_{6..9} pypy3 )
>
> The emerge command was:
>
> sudo emerge --verbose=y -vuUD --verbose-conflicts dev-python/setuptools
> dev-python/setuptools_scm dev-python/certifi dev-python/markupsafe
> dev-python/jinja dev-libs/libxml2
>
>
[gentoo-user] override PYTHON_TARGETS to avoid a slot collision
In an update with several slot collisions (see attachment), I'm
zero-ing in on the simplest, where a package is to be replaced by the
same package, but with different PYTHON_TARGETS (at least, that's how I
interpret it).
Is there a way to force the PYTHON_TARGETS of the dependency?
Slot collision:
dev-python/jinja:0
(dev-python/jinja-2.11.2-r1:0/0::gentoo, ebuild scheduled for merge)
USE="-doc -examples -test" ABI_X86="(64)" PYTHON_TARGETS="*python3_8
python3_9 (-pypy3) -python3_6 -python3_7*" pulled in by
dev-python/jinja[python_targets_python3_9(-),python_single_target_python3_9(+)]
required by (sys-auth/pambase-20201103:0/0::gentoo, ebuild scheduled for
merge) USE="nullok passwdqc sha512 -caps -debug -elogind -gnome-keyring
-minimal -mktemp -pam_krb5 -pam_ssh -pwhistory -pwquality -securetty
(-selinux) -systemd" ABI_X86="(64)"
dev-python/jinja (Argument)
(dev-python/jinja-2.11.2-r1:0/0::gentoo, installed) USE="-doc
-examples -test" ABI_X86="(64)" PYTHON_TARGETS="*python3_7 (-pypy3)
-python3_6 -python3_8 -python3_9*" pulled in by
dev-python/jinja[python_targets_pypy3(-)?,python_targets_python3_6(-)?,python_targets_python3_7(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]
required by (dev-python/sphinx-3.2.1:0/0::gentoo, installed) USE="-doc
-latex -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3)
-python3_6 -python3_8 -python3_9"
If the package was good enough before, it's likely still good enough.
Where's the problem? I've (unsuccessfully) made these attempts:
# */* PYTHON_TARGETS: python3_6 python3_7 python3_8 python3_9
#*/* PYTHON_TARGETS: -python3_6 -python3_7 python3_8 python3_9
# just have one set
*/* PYTHON_TARGETS: python3_8
The sphinx ebuild has no targets, but does have this:
PYTHON_COMPAT=( python3_{6..9} pypy3 )
The emerge command was:
sudo emerge --verbose=y -vuUD --verbose-conflicts
dev-python/setuptools dev-python/setuptools_scm dev-python/certifi
dev-python/markupsafe dev-python/jinja dev-libs/libxml2
# vim: syntax=emerge-out
These are the packages that would be merged, in order:
Calculating dependencies
* IMPORTANT: 9 news items need reading for repository 'gentoo'.
* Use eselect news read to view new items.
* See the CONFIGURATION FILES and CONFIGURATION FILES UPDATE TOOLS
* sections of the emerge man page to learn how to update config files.
. done!
[ebuild U ] sys-libs/glibc-2.32-r2:2.2::gentoo [2.31-r6:2.2::gentoo]
USE="(crypt) multiarch (multilib) ssp (static-libs) -audit -caps (-cet)
-compile-locales -custom-cflags -doc -gd -headers-only -nscd -profile
(-selinux) -static-pie -suid -systemtap -test (-vanilla)" 16369 KiB
[ebuild U ] sys-libs/timezone-data-2020d::gentoo [2020a::gentoo] USE="nls
-leaps-timezone -zic-slim%" 647 KiB
[ebuild U ] sys-devel/gcc-config-2.3.2-r1::gentoo [2.3.2::gentoo]
USE="(cc-wrappers%*) (native-symlinks)" 0 KiB
[ebuild U ] virtual/tmpfiles-0-r1::gentoo [0::gentoo] 0 KiB
[ebuild U ] dev-libs/mpc-1.2.1:0/3::gentoo [1.2.0:0/3::gentoo]
USE="-static-libs" ABI_X86="(64) -32 (-x32)" 820 KiB
[ebuild U ] sys-libs/libseccomp-2.4.4::gentoo [2.4.3::gentoo]
USE="-static-libs" ABI_X86="(64) -32 (-x32)" 591 KiB
[ebuild R] sys-apps/file-5.39-r3::gentoo USE="bzip2 seccomp zlib -lzma
-python -static-libs" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python3_8*
python3_9* -python3_6 -python3_7*" 0 KiB
[ebuild R] app-misc/pax-utils-1.2.6::gentoo USE="seccomp -caps -debug
-python" PYTHON_SINGLE_TARGET="python3_9%* -python3_6 -python3_7* -python3_8" 0
KiB
[ebuild U ] sys-apps/sandbox-2.20::gentoo [2.18::gentoo] ABI_X86="(32)
(64) (-x32)" 419 KiB
[ebuild U ] dev-libs/openssl-1.1.1i:0/1.1::gentoo [1.1.1g:0/1.1::gentoo]
USE="asm zlib -bindist -rfc3779 -sctp -sslv3 -static-libs -test -tls-heartbeat
-vanilla" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="(sse2)" 9579 KiB
[ebuild U ] sys-devel/automake-1.16.2-r1:1.16::gentoo
[1.16.1-r1:1.16::gentoo] USE="-test" 1510 KiB
[ebuild U ] sys-libs/gdbm-1.18.1-r1:0/6::gentoo [1.18.1:0/6::gentoo]
USE="berkdb nls readline -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild U ] sys-apps/attr-2.4.48-r4::gentoo [2.4.48-r3::gentoo] USE="nls
(split-usr) -debug -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild U ] sys-apps/grep-3.5::gentoo [3.4::gentoo] USE="nls pcre -static"
1550 KiB
[ebuild U ] dev-libs/popt-1.18::gentoo [1.16-r2::gentoo] USE="nls
-static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB
[ebuild U ] sys-devel/bison-3.7.3::gentoo [3.7.1-r1::gentoo] USE="nls
-examples -static -test" 2563 KiB
[ebuild U ] app-crypt/gnupg-2.2.20-r2::gentoo [2.2.20-r1::gentoo]
USE="bzip2 nls readline smartcard ssl -doc -ldap (-selinux) -tofu -tools -usb
-user-socket -wks-server" 0 KiB
[ebuild U ]
