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 :/ https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-gfx/eog-plugins/eog-plugins-3.12.1-r1.ebuild?hideattic=0&r1=1.1&r2=1.2 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.
commit 5b79880717be09eabc319b0330dee3216a069501 Author: David Seifert <soap@gentoo.org> AuthorDate: Mon Apr 17 18:46:17 2017 Commit: David Seifert <soap@gentoo.org> CommitDate: Mon Apr 17 18:48:22 2017 media-gfx/eog-plugins: Port to python-single-r1 Bug: https://bugs.gentoo.org/show_bug.cgi?id=615316 Package-Manager: Portage-2.3.5, Repoman-2.3.2 Closes: https://github.com/gentoo/gentoo/pull/4434 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.