Created attachment 557148 [details] build.log On one of my Gentoo boxes the package installs xpath in "/usr/script" instead of "/usr/bin": [...] Installing /var/tmp/portage/dev-perl/XML-XPath-1.420.0/image/usr/script/xpath * Fixing packlist file /usr/lib64/perl5/vendor_perl/5.24.3/x86_64-linux/auto/XML/XPath/.packlist >>> Completed installing XML-XPath-1.420.0 into /var/tmp/portage/dev-perl/XML-XPath-1.420.0/image/ * Final size of build directory: 764 KiB * Final size of installed tree: 236 KiB * The ebuild is installing to one or more unexpected paths: * * /usr/script * * Please fix the ebuild to use correct FHS/Gentoo policy paths. [...] I can reproduce this issue with any version currently in the Portage Tree: * 1.130.0-r1 * 1.370.0 * 1.420.0
Created attachment 557150 [details] emerge --info dev-perl/XML-XPath
I'm unable to reproduce: qlist dev-perl/XML-XPath | grep -i "/xpath$" /usr/bin/xpath Care to provide: /usr/bin/perl -V /usr/bin/perl -V:bin.* /usr/bin/perl -V:script.*
Created attachment 583564 [details] perl.log Still reproducible. Here is the perl output.
This troubles me, because this package doesn't do anything particularly fancy in its installer, which might indicate this is broken in ExtUtils::MakeMaker, and if so, I can expect many other packages to be possibly doing this. Just have to find some other packages employing: https://metacpan.org/source/MANWAR/XML-XPath-1.44/Makefile.PL#L15 And see if its doing the same thing. ( Are there other entries in /usr/script by chance? )
I forgot it occurs with "dev-python/subunit" as well. Now I tried emerging "app-shells/psh" and "dev-perl/rename", and they use the wrong directory as well ("dev-perl/rename" dies in src_install(), since the executable is installed in "${D}"/usr/script/). These are the only entries in the script directory right now: > ls /usr/script psh subunit-diff xpath
(In reply to Scall from comment #5) > I forgot it occurs with "dev-python/subunit" as well. > > Now I tried emerging "app-shells/psh" and "dev-perl/rename", and they use > the wrong directory as well ("dev-perl/rename" dies in src_install(), since > the executable is installed in "${D}"/usr/script/). > > These are the only entries in the script directory right now: > > > ls /usr/script > psh subunit-diff xpath Thats ... extra curious. Is that when you build subunit with USE="perl" by chance? And does it install subunit-diff in there when built with USE="-perl" ? ( Subunit is one of the few python things I have mentally filed in my head as 'uses perl in it somewhere' ). But its good we're narrowing the problem to ExtUtils-MakeMaker. The downside of it being ExtUtils-MakeMaker is that's very much a giant gob of "here be dragons".
(In reply to Kent Fredric (IRC: kent\n) from comment #6) > Thats ... extra curious. Is that when you build subunit with USE="perl" by > chance? [...] It seems that there is no perl USE flag for that package: [ebuild R ] dev-python/subunit-1.2.0-r1::gentoo USE="-static-libs -test" PYTHON_TARGETS="python2_7 python3_6 (-pypy) (-pypy3) -python3_5 (-python3_7)" 450 KiB
(In reply to Scall from comment #7) > (In reply to Kent Fredric (IRC: kent\n) from comment #6) > > Thats ... extra curious. Is that when you build subunit with USE="perl" by > > chance? [...] > > It seems that there is no perl USE flag for that package: > > [ebuild R ] dev-python/subunit-1.2.0-r1::gentoo USE="-static-libs > -test" PYTHON_TARGETS="python2_7 python3_6 (-pypy) (-pypy3) -python3_5 > (-python3_7)" 450 KiB Ugh :( But all the same, I'll need to talk with somebody upstream who understands this nonsense. :(
After the latest updates the issue do NOT occur anymore (for all the packages I mentioned in my previous comments as well), both on the first Gentoo box where I experienced the issue and another box where I experienced it later. So I guess this can be closed.
(In reply to Scall from comment #9) > After the latest updates the issue do NOT occur anymore (for all the > packages I mentioned in my previous comments as well), both on the first > Gentoo box where I experienced the issue and another box where I experienced > it later. So I guess this can be closed. Thank you for updating us!
