Bug 993374 - rxvt-unicode: FTBFS in rawhide
rxvt-unicode: FTBFS in rawhide
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: rxvt-unicode (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Andreas Bierfert
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F20FTBFS
  Show dependency treegraph
 
Reported: 2013-08-05 16:32 EDT by Dennis Gilmore
Modified: 2014-10-29 18:33 EDT (History)
6 users (show)

See Also:
Fixed In Version: rxvt-unicode-9.18-4.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-18 14:58:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dennis Gilmore 2013-08-05 16:32:04 EDT
Your package rxvt-unicode failed to build from source in current rawhide.

http://koji.fedoraproject.org/koji/taskinfo?taskID=5773006

For details on mass rebuild see https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
Comment 1 Petr Pisar 2013-08-06 08:56:16 EDT
PERL="perl" perl /usr/share/perl5/ExtUtils/xsubpp -C++ -typemap /usr/share/perl5/ExtUtils/typemap -typemap typemap.iom -typemap typemap -prototypes ./rxvtperl.xs >rxvtperl.C
perl -MExtUtils::Embed -e xsinit -- -std urxvt
Can't open perl script "/usr/share/perl5/ExtUtils/xsubpp": No such file or directory

This is because of hard-coded wrong path to xsubpp. Please use plain 'xsubpp' which is in PATH.
Comment 2 Paul Howarth 2013-08-18 14:58:26 EDT
Fixed by using /usr/bin/xsubpp for now.
Comment 3 redhat-bugzilla 2014-10-27 12:21:45 EDT
This is a bug in fedoras perl or in the fedora urxvt package, not in urxvt. rxvt-unicode upstream does NOT use hardcoded paths but uses the standard location (@PERLPRIVLIBEXP@/ExtUtils/xsubpp) where xsubpp is installed, i.e. it takes the path from the perl configuration - if xsubpp isn't there, then the perl config is broken or the perl package misses the file.

While hardcoding the path in fedoras urxvt package might be a solution that works for fedora (by ensuring xsubpp matches the perl version), it would be better to fix the fedora perl package to actually provide the file in the correct install location, as urxvt is not the only package that requires this file to be present in the correct location. It also gives a dangerous precedent to users of perl, who might think that hardcoding the path to xsubpp is correct, leading to packages that mysteriously fail when users use their own perl installation.

(I am speculating, but maybe this is simply a missing dependency, as fedora might split perl into multiple packages, one of which might have the file, and the other not).
Comment 4 Petr Pisar 2014-10-27 12:36:51 EDT
(In reply to redhat-bugzilla from comment #3)
> This is a bug in fedoras perl or in the fedora urxvt package, not in urxvt.
> rxvt-unicode upstream does NOT use hardcoded paths but uses the standard
> location (@PERLPRIVLIBEXP@/ExtUtils/xsubpp) where xsubpp is installed, i.e.
> it takes the path from the perl configuration - if xsubpp isn't there, then
> the perl config is broken or the perl package misses the file.
> 
No. The xsubpp can be stored in any prefix listed in perl's @INC directory. (Users can upgrade the tool independently from the distributor.) To see how it is located by the official ExtUtils::MM_Unix module, study tool_xsubpp() in <http://cpansearch.perl.org/src/BINGOS/ExtUtils-MakeMaker-7.00/lib/ExtUtils/MM_Unix.pm>.

So with your stick-on-upstream mantra, you can implement this silly lookup function into the rxvt-unicode.

Or you can benefit from Fedora which adds a symlink into FHS compliant /usr/bin.
Comment 5 redhat-bugzilla 2014-10-27 17:16:01 EDT
Wow, this is wrong in so many ways.

First, while you can have additional ones, the one that comes with perl is installed in privlibexp, and this is what urxvt is interested in. ExtUtils::MakeMaker is a dual-life module and thus can be installed multiple times (even outside the default path) and has to do extra work. urxvt is not using ExtUtils::MakeMaker, it embeds perl.

Secondly, upgrading it independently will not delete the original version that came with perl, so if its missing, its not missing due to the user, so this explanation doesn't apply.

Thirdly, the FHS says nothing about xsubpp going to /usr/bin or anywhere else, the xsubpp we are talking about here is an internal tool of ExtUtils::MakeMaker.

(stopped counting), perl installs a copy in the binpath (which hopefully is /usr/bin on fedora) for a long time. If fedora replaces it by a symlink that's just another minor incompatibility to upstream perls. Very minor, in fact, but still a needless deviation. Or in other words, its certainly not a benefit of fedora, but something that people might have to work around again (and there is a long history of needless such changes, consider Task::Weaken for example).

Lastly, it's still better to provide the binary in the location where upstream perls install it, rather than hardcoding paths.

If fedora isn't sure about why to make a change, it simply shouldn't do it.
Comment 6 Petr Pisar 2014-10-29 03:02:01 EDT
Thank you for your insightfull  view, but Fedora is not Perl upstream. Fedora removes core modules updated by CPAN dual-lived modules due to security and technical (release engineering tools cannot deal with same-named RPM packages) reasons. And this will not change.
Comment 7 redhat-bugzilla 2014-10-29 18:33:06 EDT
well, thanks at least for clarifying that this is a limitation in fedoras toolset, although it is not clear why it couldn't be fixed - perl deals with security updates without having to delete files from an installed perl (which is absolutely necessary because normal users cnanot delete perl base files), so its not clear why fedora couldn't simply rely on that mechanism (other distributions such as debian gnu/linux also do not need to patch their perl/remove files for security updates).

in any case, this vindicates my original point, namely that fedora deviates from upstream, in which case it should also deal with the resulting breakage instead of it leaking into upstream.

Note You need to log in before you can comment on or make changes to this bug.