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. ------------- perl-SQL-Translator http://koji.fedoraproject.org/koji/taskinfo?taskID=1933182 from build.log: error: Installed (but unpackaged) file(s) found: /blib/lib/auto/share/dist/SQL-Translator/DiaUml/diagram.tt2 /blib/lib/auto/share/dist/SQL-Translator/DiaUml/layer.tt2 /blib/lib/auto/share/dist/SQL-Translator/DiaUml/schema.tt2 ....etc, etc
perl-DBI-Dumper http://koji.fedoraproject.org/koji/taskinfo?taskID=1933271 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: /builddir/build/BUILD/DBI-Dumper-2.01/blib/arch/auto/DBI/Dumper/C/C.so Installed (but unpackaged) file(s) found: /builddir/build/BUILD/DBI-Dumper-2.01/blib/arch/auto/DBI/Dumper/C/C.so
perl-Padre 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/*
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 ] unset MODULEBUILDRC unset PERL_MM_OPT [ try building again ] make local [ oops - fails ] RPM build errors: Installed (but unpackaged) file(s) found: /home/iarnell/tmp/fc/perl-DBI-Dumper/F-12/DBI-Dumper-2.01/blib/arch/auto/DBI/Dumper/C/C.so
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)
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
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.
On the other hand, it's really strange that only some modules have problems. Couldn't be problem with their Makefile? Thoughts?
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).
(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.
*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 v6.51_01 ...etc http://github.com/schwern/extutils-makemaker/commit/58ec782413fdfb03f30c0de39131e7eb228f8bc9 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.)
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.
(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.
https://rt.cpan.org/Public/Bug/Display.html?id=53913 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.
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.
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.
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?
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.
Created attachment 389061 [details] Module::Build is checked
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).
(With apologies for mangling your name, Iain.)
FTBFS fixed in perl-5.10.1-110.fc13. Closing.
Was accidentally closed by the ftbfs autocloser. Reopening. -Matt