src_install() { installation() { emake DESTDIR="${D}" install mv "${ED}"/usr/bin/pykdeuic4-{${EPYTHON/python/},${EPYTHON}} || die python_optimize } python_foreach_impl run_in_build_dir installation dosym python-exec /usr/bin/pykdeuic4 (snip) I'm not even sure if it's allowed by the Geneva convention. In any case, it's terribly fragile.
FYI: I've forced python-exec:0 in the ebuild now. We will probably revisit your sinister ways near python-exec:2 going stable, so please keep the bug open.
BTW I'm not sure if it's exactly the same but you can take a look at e.g. dev-python/unittest2. Its setup.py installs both 'foo' and 'foo-X.Y', and the eclass simply wraps both. While it may be a little unnecessary, it gives 100% consistent behavior -- that is, there's: - foo which supports all simpls, - foo-pythonX.Y, - foo-X.Y which support only X.Y impl, - foo-X.Y-pythonX.Y (only for matching X.Y) :).
(In reply to Michał Górny from comment #0) > I'm not even sure if it's allowed by the Geneva convention. In any case, > it's terribly fragile. Don't blame us, we had this voodoo review by python team before committing. ;-) pykde4 has no setup.py, but upstream has introduced the option PYKDEUIC4_ALTINSTALL which appears to make the build system automagically name the binary the way we hack it now. I will test this option.
(In reply to Michael Palimaka (kensington) from comment #3) > pykde4 has no setup.py, but upstream has introduced the option > PYKDEUIC4_ALTINSTALL which appears to make the build system automagically > name the binary the way we hack it now. I will test this option. I don't really want to (rebuild and) install all the necessary dependencies, so if you're going to change it, I'd appreciate if you could test it as well with python-exec:2 (you'll need to unmask it).
No problem, will do.
(In reply to Michael Palimaka (kensington) from comment #5) > No problem, will do. @Michael: Any news on this?
OK, pykde4 installs /usr/bin/pykdeuic4-X.Y, which we hack to pykdeuic4-python3.2, which is a symlink to /usr/lib64/pythonX.Y/site-packages/PyQt4/uic/pykdeuic4.py. . PYKDEUIC4_ALTINSTALL controls whether to create symlink /usr/bin/pykdeuic4 to /usr/bin/pykdeuic4-X.Y - and we disable these symlinks and create them in the ebuild. This fails with python-exec:2, I guess because the symlinks are installed into /usr/bin. I guess we could revert to the original behaviour (build system creates /usr/bin/pykdeuic4 -> /usr/bin/pykdeuic4-X.Y) then run python_replicate_script for each implementation? I don't think we have any particular preference about how this is handled, and I'm happy to test any suggestions you have.
Successful compiled against dev-python/PyQt4-4.11.1.
This bug is not related to the PyQt4-4.11 build failure.
We'll get rid of this package by stabilising KDE Applications 17.04 and last-riting the last remaining rdep (kde-misc/kanyremote).
has it been last-rited already?
Afaik kensington was working on a kanyremote version bump, but it seems that doesn't work all that well.
Package masked for removal in git commit a28d39293c44377d011e7f8fe80814424aac6669
