eog-plugins has a REQUIRED_USE
python? ( exactly-one-of ( python_targets_python3_4 python_targets_python3_5 ) )
which feels wrong to me and candidate for python-single-r1 or something. Just one of these libpeas things I think. While at it, might want to try python3_6 out too.
This was introduced here by mgorny... he probably will know if we can improve this :/
If we agree on keeping this, we must remember to add a commented line explaining for not bothering him again for the same in the future ;)
I suppose it was because of revdeps.
> Use python-r1 to avoid issues with python-single-r1 when depending on libpeas.
Ok, figured it out. So it's relevant to bug #530684.
Basically, due to technical limitations python-single-r1 -> python-r1 deps are done via PYTHON_TARGETS which are superset of PYTHON_SINGLE_TARGET in python-single-r1 packages (via REQUIRED_USE).
So even though you build eog-plugins with a single target only, you can still have multiple PYTHON_TARGETS selected. The eclass only ensures that the one matching PYTHON_SINGLE_TARGET is selected; others are ignored as no-op. However, they influence dependencies.
So if you have e.g. PST=3.4 PT="3.4 3.5", eog-plugins will by default force [3.4,3.5] on libpeas via USE-dep which in turn will trigger REQUIRED_USE problem on libpeas because it allows only one of 3.*.
For this reason, I had to add an equivalent REQUIRED_USE to libpeas revdeps to ensure that it does not enforce impossible USE-deps. Of course, if this REQUIRED_USE is in place, then there's no reason to use python-single-r1 and add redundant flags.
PYTHON_TARGETS="python3_4 python3_5" PYTHON_SINGLE_TARGETS="python3_4" needing further manual tweaking per-package is very uncool. But I can't grok the reasoning yet, but it seems it might be necessary. I need to look closer as a lower priority, but any ideas what could be done? Some splitting of single and multi uses from package or anything?
err, eog-plugins doesn't have any rdeps, can't we just single it?
(In reply to Mart Raudsepp from comment #6)
> err, eog-plugins doesn't have any rdeps, can't we just single it?
But it depends on libpeas, and enforces impls on libpeas. If you single it, and user has PT="3.4 3.5", it will enforce REQUIRED_USE breakage on libpeas, and I doubt Portage will do anything except wreaking havoc.
So I understand a clean solution would be to do something with libpeas, support multiple python3's at once or something.
Other than that, would having libpeas[python] consumers doing their own PYTHON_USEDEP replacement based on what single target is picked too crazy?
It's not worth the effort. Just switch libpeas to single-r1, it has no real use for py2 loader anymore. Soap is already working on this.
I don't see how this solves the issue at hand wrt REQUIRED_USE ^^ in eog-plugins, unless libpeas can already have co-existing py3 versions, just not together with py2
If all packages are single-r1, the PYTHON_TARGETS don't have REQUIRED_USE and we have no switching for users.
Author: David Seifert <firstname.lastname@example.org>
AuthorDate: Mon Apr 17 18:46:17 2017
Commit: David Seifert <email@example.com>
CommitDate: Mon Apr 17 18:48:22 2017
media-gfx/eog-plugins: Port to python-single-r1
Package-Manager: Portage-2.3.5, Repoman-2.3.2
Are we done here?
I think so. I didn't understand the magic on how it then doesn't use dep on both PT versions, but ok, as long as it doesn't.