Summary: | dev-perl/XML-XPath should not install /usr/script/xpath but /usr/bin/xpath | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Scall <scall> |
Component: | Current packages | Assignee: | Gentoo Perl team <perl> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | kentnl, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
emerge --info dev-perl/XML-XPath perl.log |
Description
Scall
2018-12-06 11:34:58 UTC
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! |