After upgrade to 2.5.0, only the following files are installed which look more like a binary than a link install as there are no header files. ~ # qlist duktape /usr/lib64/libduktape.so.204 /usr/lib64/libduktape.so.204.20400 /usr/lib64/pkgconfig/duktape.pc
The previous version had the following: ~ # qlist duktape /usr/lib64/libduktape.so /usr/lib64/libduktape.so.204 /usr/lib64/pkgconfig/duktape.pc /usr/lib64/libduktape.so.204.20400 /usr/lib64/libduktaped.so.204.20400 /usr/include/duktape.h /usr/include/duk_config.h /usr/lib64/libduktaped.so.204 /usr/lib64/libduktaped.so
Created attachment 646836 [details, diff] ducktape-2.5.0.ebuild.patch This fixes the way how it install files. Problem is that because of ${D::-1} it removes last symbol from ${D} and install headers to `/var/tmp/portage/dev-lang/duktape-2.5.0/imag` which is not a valid folder.
This is due to EAPI=7 no longer have trailing slash in some variables, including D. So it's now harmful to remove last symbol before doing sed. For original ebuild author correct way was to use ${D%/} instead of ${D::-1} currently in use in the ebuild. That way this issue would never surface.
*** Bug 729936 has been marked as a duplicate of this bug. ***
*** Bug 729842 has been marked as a duplicate of this bug. ***
the proposed fix seems to be working with cross compile
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=10cf094cdd34df34e8085e3ab615a7a7988bbad8 commit 10cf094cdd34df34e8085e3ab615a7a7988bbad8 Author: Ian Whyman <thev00d00@gentoo.org> AuthorDate: 2020-06-28 08:52:04 +0000 Commit: Ian Whyman <thev00d00@gentoo.org> CommitDate: 2020-06-28 08:52:04 +0000 dev-lang/duktape: Fix header install Closes: https://bugs.gentoo.org/729914 Closes: https://bugs.gentoo.org/729840 Package-Manager: Portage-2.3.103, Repoman-2.3.23 Signed-off-by: Ian Whyman <thev00d00@gentoo.org> dev-lang/duktape/{duktape-2.5.0.ebuild => duktape-2.5.0-r1.ebuild} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
*** Bug 729960 has been marked as a duplicate of this bug. ***