Something ain't quite right with dev-tcltk/blt. Bug 259338 is cited as the reason to inject pkgIndex.tcl from ${FILESDIR} instead of allowing the standard installation process to put it there. This may have been a good-enough "solution" to the problem at some point... and for all I know about this pkgIndex.tcl file (literally nothing), perhaps it doesn't much matter or still suffices. However, something super-ugly happens during emake install in the library sub-directory: make[1]: Entering directory `/var/tmp/portage/dev-tcltk/blt-2.4z-r12/work/blt2.4z-8.5.2/library' mkdir /var/tmp/portage/dev-tcltk/blt-2.4z-r12/image//usr/lib mkdir /var/tmp/portage/dev-tcltk/blt-2.4z-r12/image//usr/lib64/blt2.4/dd_protocols rm -f pkgIndex.tcl sed -e 's/%VERSION%/2.4/' /var/tmp/portage/dev-tcltk/blt-2.4z-r12/image/./pkgIndex.tcl.in | \ sed -e 's/%LIB_PREFIX%/lib/' | \ sed -e 's;%LIB_DIR%;/usr/lib64;' > pkgIndex.tcl sed: can't read /var/tmp/portage/dev-tcltk/blt-2.4z-r12/image/./pkgIndex.tcl.in: No such file or directory That sure don't look right to me, no wonder we had this file go missing in bug 259338. Where is that garbage coming from? Why, from us! We pretty-much injected that trash, apparently for no good reason, when we ran the patch "${PORTDIR}/dev-tcltk/blt/files/blt-2.4z-r4-fix-makefile.patch" (src_prepare()) That patch has two hunks. The first hunk may have once served a purpose but is clearly now garbage. The second hunk is a correct, standard DESTDIR adjustment. If I remove the offending patch-hunk, redigest the ebuild and run it up to the "install" phase, I now see that the pkgIndex.tcl we are deploying no longer bears any relationship to the one generated upstream (the upstream one is correctly deployed now during emake but that is still overwritten by src_install -- for comparison purposes, the upstream-generated version can still be found at ie: ${PORTAGE_TMPDIR}/portage/dev-tcltk/blt2.4z-r12/work/blt2.4z-8.5.2/library/pkgIndex.tcl once the patch is fixed) I have no understanding of such things but I also have no reason to suspect anything is wrong with upstream's version of the file. To summarize, the only reason, it seems, that we are scribbling over upstream's file is #259338, which presumably was simply caused by our broken patch (${PV}-fix-makefile.patch), if we had just noticed... So I propose that we: o drop the first hunk of "${PORTDIR}/dev-tcltk/blt/files/blt-2.4z-r4-fix-makefile.patch", or, if we are concerned about backward-compatibility somehow, copy it to some other name, and then drop the first hunk. o remove "${PORTDIR}/dev-tcltk/blt/files/tclIndex.tcl (or leave it for backward compatibility) o apply this patch to the ebuild: --- blt-2.4z-r12.ebuild.bad 2013-09-24 10:14:39.624661245 -0700 +++ blt-2.4z-r12.ebuild 2013-09-24 10:15:31.064656707 -0700 @@ -114,9 +114,6 @@ mv "${ED}"/usr/share/man/mann/${f} "${ED}"/usr/share/man/mann/${f/.n/.nblt} done - # bug 259338 - dev-tcltk/blt-2.4z-r4 provides empty pkgIndex.tcl - cp "${FILESDIR}"/pkgIndex.tcl "${ED}"/usr/$(get_libdir)/blt2.4/pkgIndex.tcl - # fix for linking against shared lib with -lBLT or -lBLTlite dosym libBLT24$(get_libname) /usr/$(get_libdir)/libBLT$(get_libname) dosym libBLTlite24$(get_libname) /usr/$(get_libdir)/libBLTlite$(get_libname) -->8-- There, now everything looks normal again! HTH! Reproducible: Always Steps to Reproduce: emerge it Actual Results: funk Expected Results: smooth jazz We broke the Makefile, so to compensate, we broke something else, too.
Still unfixed six months later... paging tcl/tk herd, you have a phone call at the bugzilla desk...
+*blt-2.4z-r13 (28 Jul 2015) + + 28 Jul 2015; Justin Lecher <jlec@gentoo.org> +blt-2.4z-r13.ebuild, + +files/blt-2.4z-r4-fix-makefile3.patch: + Fix creation of pkgIndex.tcl, bug #485880; thanks Greg Turner for + investigation and bringing up the patch +
