Bug 557015 - ExtUtils::MakeMaker 6.51_01+ causing build failures w/Module::Install::Share and others
ExtUtils::MakeMaker 6.51_01+ causing build failures w/Module::Install::Share ...
Product: Fedora
Classification: Fedora
Component: perl (Show other bugs)
All Linux
low Severity urgent
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
Depends On: 562314 562316
Blocks: 555437 555496 557261
  Show dependency treegraph
Reported: 2010-01-20 00:49 EST by Chris Weyl
Modified: 2010-02-14 20:29 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-02-13 22:36:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
perl-DBI-Dumper build log with EU::MM 6.42 (8.30 KB, application/octet-stream)
2010-01-20 23:56 EST, Iain Arnell
no flags Details
perl-DBI-Dumper build log with EU::MM 6.56 (9.03 KB, application/octet-stream)
2010-01-20 23:57 EST, Iain Arnell
no flags Details
Module::Build is checked (1.21 KB, application/x-awk)
2010-02-05 07:09 EST, Marcela Mašláňová
no flags Details

  None (edit)
Description Chris Weyl 2010-01-20 00:49:45 EST
Recent rawhide builds of perl have radically changed the module directory structures, including making vendor == core.  This has confused the standard build tools, the most visible of which is Module::Install's install_share().  We see this as the install phase gets the target directories wildly wrong, causing builds to fail with a buildroot/%files mismatch.

See, e.g., the below.  I'll attach more as I find them.


from build.log:

error: Installed (but unpackaged) file(s) found:
....etc, etc
Comment 1 Chris Weyl 2010-01-20 01:37:54 EST

from build.log:

hecking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/perl-DBI-Dumper-2.01-9.fc13.x86_64
error: Installed (but unpackaged) file(s) found:
    Installed (but unpackaged) file(s) found:
Comment 2 Chris Weyl 2010-01-20 15:48:44 EST

This build is impacted by this issue and _should_ fail, except for the following addition to the spec in rawhide:

rm -rf $RPM_BUILD_ROOT/blib/lib/auto/share/dist/Padre/*
Comment 3 Iain Arnell 2010-01-20 23:52:36 EST
It's the newer version of ExtUtils::MakeMaker in devel that's causing the problem, not the changes to module directory structure.

On a standard F-12 box with standard perl-5.10.0-87.fc12.x86_64,

[ try building perl-DBI-Dumper (or anything else that fails in devel
with stuff "installed" into /blib) ]
fedora-cvs perl-DBI-Dumper
cd perl-DBI-Dumper/F-12
make local
[ works as expected ]

[ manually upgrade ExtUtils::MakeMaker to latest version ]
eval `perl -Mlocal::lib`
perl -MCPAN -e 'install "ExtUtils::MakeMaker"'

[ cleanup environment ]

[ try building again ]
make local

[ oops - fails ]
RPM build errors:
   Installed (but unpackaged) file(s) found:
Comment 4 Iain Arnell 2010-01-20 23:56:04 EST
Created attachment 385844 [details]
perl-DBI-Dumper build log with EU::MM 6.42

make local for perl-DBI-Dumper works fine with stock F12 ExtUtils::MakeMaker 6.42 (although the RPM is actually perl-ExtUtils-MakeMaker-6.36-87.fc12.x86_64)
Comment 5 Iain Arnell 2010-01-20 23:57:00 EST
Created attachment 385845 [details]
perl-DBI-Dumper build log with EU::MM 6.56

make local for perl-DBI-Dumper fails with manually installed ExtUtils-MakeMaker 6.56
Comment 6 Marcela Mašláňová 2010-01-21 07:55:00 EST
The bug is really in ExtUtils::MakeMaker. The problem is occuring since 6.51_01.
Version 6.50 is the last working one.

Experiments were also done on perl-DBI-Dumper.
Comment 7 Marcela Mašláňová 2010-01-21 09:54:56 EST
On the other hand, it's really strange that only some modules have problems. Couldn't be problem with their Makefile? Thoughts?
Comment 8 Iain Arnell 2010-01-21 10:25:45 EST
The problem seems to be triggered by modules that make use of EU::MM postamble in their Makefile.PL (either directly as in the case of DBI-Dumper, or indirectly by using Module::Install::Share in the case of Padre, SQL-Translator, and HTML-FormFu).
Comment 9 Iain Arnell 2010-01-21 23:13:23 EST
(In reply to comment #6)
> The bug is really in ExtUtils::MakeMaker. The problem is occuring since
> 6.51_01.
> Version 6.50 is the last working one.

Indeed - looks to be the fix for http://rt.cpan.org/Public/Bug/Display.html?id=32758 that is causing the problem.
Comment 10 Chris Weyl 2010-01-22 00:37:51 EST
*sigh* I suppose that's what I get for really wanting to blame it on the @INC changes.

Poking at EU::MM's git repo up on github, it looks like that change was definitely introduced in 6.51_01:

[cweyl@athena ExtUtils]$ git blame -L 2062,2062 MM_Unix.pm 
58ec7824 (Michael G Schwern 2009-04-09 01:33:33 +0000 2062) pure_site_install :: all
[cweyl@athena ExtUtils]$ git tag --contains 58ec7824


Which in turn points to https://rt.cpan.org/Public/Bug/Display.html?id=32758 -- namely that this was changed to better support parallel make installs, ensuring that the "all" target completes before various other install targets are attempted.  My make-fu is painfully limited, so it sounds reasonable...  And I'm not entirely sure how to address it short of reverting it.  (Or spec macro magic wrapping %__spec_install_post to nuke any /blib, which sounds painful, and would probably provoke a lot of yelling.)
Comment 11 Marcela Mašláňová 2010-01-22 03:25:11 EST
So what now, do you agree with reverting this change for the meantime and creating bug report for upstream?
I verified that this revert fix the problem. Also I had another problem with Padre and that also disappeared. Test were incorrectly detecting need of WIN32::API.
Comment 12 Ralf Corsepius 2010-01-22 05:22:11 EST
(In reply to comment #11)
> So what now, do you agree with reverting this change for the meantime and
> creating bug report for upstream?
No. I would suggest to report this issue to upstream and wait for upstream to react for say 1 or 2 weeks.

May-be upstream has a strong opinion on this (e.g. "behavioral change, the packages having issues with it need to be modified", or "Oops, my mistake, will revert the change").

May-be we will be able to gain a clearer view on the problem, during this time.

I am inclined to consider "reverting now" to be a knee-jerk overreaction.
Comment 13 Marcela Mašláňová 2010-01-26 08:02:39 EST

Check upstream reaction. The problem is that if you try perl Makefile.PL && make simply from tar.gz you can see that some files are installing into blib in make part. Which shouldn't be doing.
Comment 14 Marcela Mašláňová 2010-02-04 12:26:05 EST
Well, I was able to reproduce it even on clean build, so it is not caused by our changes. The same problem is reproducible in debian unstable. It is also possible that these modules have something wrong in their configuration.
Comment 15 Marcela Mašláňová 2010-02-04 12:28:25 EST
Also I was told that problems with installation in SQL::Translator are caused by Module::Install and not by ExtUtils::MakeMaker even if revert of patch fixed it.
Comment 16 Iain Arnell 2010-02-04 23:17:36 EST
I thought the upstream comment was quite clear.  The problem is that for whatever reason, we've always been using 

make pure_install PERL_INSTALL_ROOT=/path/to/buildroot

But apparently, this is quite specific to ExtUtils::MakeMaker. For Module::Install, we should be passing DESTDIR instead of PERL_INSTALL_ROOT. Doing so certainly works properly for perl-HTML-FormFu (the only package of mine that was affected). 

Assuming it works that way for SQL::Translator and Padre too, I think problem is pretty much solved (except maybe changing cpanspec to do the right thing automatically). 

Unfortunately, using DESTDIR doesn't help DBI-Dumper. But it's doing something unusual with EU::MM postamble - maybe it's just doing the wrong thing?
Comment 17 Marcela Mašláňová 2010-02-05 07:04:02 EST
I believe 'make' have to do the right thing without parameter, but ok. DESTDIR solve this for two mentioned packages and the third doesn't use Module::Build.

I'm proposing a patch for cpanspec to change to DESTDIR everytime Module::Install is used. Reassigning to cpanspec.
Comment 18 Marcela Mašláňová 2010-02-05 07:09:11 EST
Created attachment 389061 [details]
Module::Build is checked
Comment 19 Chris Weyl 2010-02-05 17:00:35 EST
I do have to concur with Iaian here, upstream was pretty clear here about using DESTDIR vs PERL_INSTALL_ROOT.  Making this change does seem to resolve the non-arch specific packages running into this (e.g. perl-SQL-Translator vs perl-DBI-Dumper).

Have we figured out what what caused DBI-Dumper and the other arch specific packages to fail?  Until we do that, we should probably keep this bug pointing at the perl package, and file other bugs against cpanspec (and rpmdevtools for new specs, I'd imagine).
Comment 20 Chris Weyl 2010-02-05 17:55:11 EST
(With apologies for mangling your name, Iain.)
Comment 21 FTBFS 2010-02-13 22:36:24 EST
FTBFS fixed in perl-5.10.1-110.fc13.  Closing.
Comment 22 FTBFS 2010-02-14 20:29:48 EST
Was accidentally closed by the ftbfs autocloser.  Reopening. -Matt

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