root# qlist -e libbytesize /usr/include/bytesize/bs_size.h /usr/lib64/libbytesize.so.1 /usr/lib64/libbytesize.so.1.0.0 /usr/lib64/python2.7/site-packages/bytesize/__init__.py /usr/lib64/python2.7/site-packages/bytesize/bytesize.py /usr/lib64/pkgconfig/bytesize.pc /usr/lib64/libbytesize.la /usr/lib64/libbytesize.so /usr/share/doc/libbytesize-1.2/README.md.bz2 /bytesize/__init__.py /bytesize/bytesize.py
I cannot reproduce this issue. Can you please post the output of emerge --info libbytesize to this bug?
Created attachment 502810 [details] emerge --info libbytesize Attaching the output of "emerge --info libbytesize".
The issue here is that src/python/Makefile.am calls both the python and python3 binaries to support python2 and python3, but the ebuild uses python-single-r1.eclass. When python_single_target USE flags are set to python3 all is fine, because both python and python3 calls will resolve to the same install path and the package will just install the files twice to the same location. When the USE flags are set to python2 the python call will install to python2 library path. Calling the python3 binary will result in an error, because python-single-r1.eclass has set up a wrapper script, and the install prefix will be an empty string, i.e. the root prefix.
Created attachment 509206 [details, diff] support for multiple python versions Just sticking in --without-python3 should be enough, although it is irritating as python3 is still supported. Installation for multiple python versions is also easy as it just installs the .py files multiple times.
I added a patched libbytesize-1.2-r1 to my overlay: https://github.com/stefantalpalaru/gentoo-overlay I fixed Python3 support by using python_is_python3() and python_foreach_impl() in src_configure().
The logic in your ebuild does not work the way you assume. When configuring the package for multiple interpreter versions you need to use python_copy_sources to copy the source tree, else you're just re-configuring the same source tree all over again and the last one gets used effectively. And as the package does not perform any specific python discovery during configure, there is no need to configure for multiple python versions. Also using python_is_python3 does not provide any benefit, because for the python3 implementation both the python and the python3 binary will point to python3. Just always using --without-python3 and having the package use the main python binary during installation of the python libraries is better.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7e6e3f74766d67f12a6d1edbf317133545c214c7 commit 7e6e3f74766d67f12a6d1edbf317133545c214c7 Author: Sven Wegener <swegener@gentoo.org> AuthorDate: 2017-12-13 13:40:06 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2017-12-13 13:40:51 +0000 dev-libs/libbytesize: Revbump to fix creation of top-level directory. Closes: https://bugs.gentoo.org/634840 Package-Manager: Portage-2.3.18, Repoman-2.3.6 .../{libbytesize-1.2.ebuild => libbytesize-1.2-r1.ebuild} | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
It happens again with version 1.3.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5ce3ae1f3b1d4eac5c2b1b737256fbc60cfa93e8 commit 5ce3ae1f3b1d4eac5c2b1b737256fbc60cfa93e8 Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2018-04-23 07:30:27 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2018-04-23 07:30:42 +0000 dev-libs/libbytesize: Revbump to not create top-lvel directory (again). Bug: https://bugs.gentoo.org/634840 Package-Manager: Portage-2.3.31, Repoman-2.3.9 .../{libbytesize-1.3.ebuild => libbytesize-1.3-r1.ebuild} | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-)}
