| Summary: | g-cpan -i XML::SAX::ExpatXS fails in installation phase: can't locate XML/SAX/ExpatXS.pm in @INC | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Richard Brown (RETIRED) <rbrown> |
| Component: | [OLD] Development | Assignee: | Gentoo Perl team <perl> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | normal | CC: | jgeisler, perl |
| Priority: | High | ||
| Version: | 2005.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | g-cpan | ||
| Package list: | Runtime testing required: | --- | |
|
Description
Richard Brown (RETIRED)
2005-08-04 07:25:21 UTC
Mass re-assign. Below is part of Makefile.PL from XML::SAX::ExpatXS that is causing the
installation error. Notice how install_expat_xs is appended to the install
target. When the install target is called it starts a new Perl process which
expects the XML::SAX::ExpatXS .pm to already be installed. Adding the "image"
directory to @INC so the Makefile can continue ie:
PERL5LIB=/var/tmp/portage/XML-SAX-ExpatXS-1.08/image/usr/lib/perl5/vendor_perl/5.8.6
g-cpan -i XML-SAX-ExpatXS
returns a sandbox error because it tries to write to the file:
/usr/lib/perl5/vendor_perl/5.8.6/XML/SAX/ParserDetails.ini
Makefile.PL snippet that is the source of the problem:
sub MY::install {
package MY;
my $script = shift->SUPER::install(@_);
if (ExtUtils::MakeMaker::prompt("Do you want to alter ParserDetails.ini?",
"Y") =~ /^y/i) {
$script =~ s/install :: (.*)$/install :: $1 install_expat_xs/m;
$script .= <<"INSTALL";
install_expat_xs :
\t\@\$(PERL) -MXML::SAX -e
"XML::SAX->add_parser(q(XML::SAX::ExpatXS))->save_parsers()"
INSTALL
yeeeks, I didn't even realize this bug existed until the last cc added themselves overnight. Let's see - interactive modules (like the prompting for adding to parsedetails in this case) are always going to be a problem for g-cpan (even if there have been a ton of changes since this original post). In this particular case, I'd recommend editing the generated ebuild and adding this to the bottom:
src_unpack() {
unpack ${A}
sed -i -e "s|y/|n/|" ${S}/Makefile.PL
}
then running
ebuild XML-SAX-ExpatXS-1.20.ebuild digest
to regenerate the digest.
That is not the primary bug on this. And in fact, there is another Bugzilla bug opened for that kind of problem by me (42189). The bigger problem is that the module expects itself to be installed during a postinstall make target so that it can modify a file that really does need to be modified so that the XML::SAX::ParserFactory can instantiate this module if called upon to do so. Unfortunately, I had already worked around this problem by using cpan to install the module and then using g-cpan to re-install the module so that I can track any future updates through portage. g-cpan isn't perfect - can't be. Module authors rarely follow the same recipe twice. I'm afraid this is a can't fix kind of bug -its outside the scope of an app like g-cpan to be able to account for absolutely every possibility in cpan i'm afraid. many moons later, actually marking it cantfix this time (sorry for the shout from the past) |