Skip Menu |

This queue is for tickets about the ExtUtils-MakeMaker CPAN distribution.

Report information
The Basics
Id: 53913
Status: resolved
Priority: 0/
Queue: ExtUtils-MakeMaker
People
Owner: Nobody in particular
Requestors: mmaslano [...] redhat.com
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: 6.51_01
Fixed in: (no value)
Attachments
build-fail
build-pass

History Show all quoted text
  Fri Jan 22 06:14:50 2010 mmaslano [...] redhat.com - Ticket created
Subject: unpackaged blib directories
It was found out that some packages can't be rebuild into rpm with latest update of ExtUtils::MakeMaker. I was able to track down the problem. The last "functional" version was 6.50 and problems started with 6.51_01 git commit http://github.com/schwern/extutils-makemaker/commit/58ec782413fdfb03f30c0de39131e7eb228f8bc9 Also not all packages have problems. At the moment I'm aware of those: DBI::Dumper and Padre, but after next rebuild, we'll probably see more of them. They created directory blib which is now forced to be packaged/installed even if it's already once in package. For example DBI::Dumper build ended with: error: Installed (but unpackaged) file(s) found: /tmp/perl-DBI-Dumper/devel/DBI-Dumper-2.01/blib/arch/auto/DBI/Dumper/C/C.so Padre: RPM build errors: Installed (but unpackaged) file(s) found: /blib/lib/auto/share/dist/Padre/README.txt /blib/lib/auto/share/dist/Padre/doc/perlopref/Artistic /blib/lib/auto/share/dist/Padre/doc/perlopref/Copying /blib/lib/auto/share/dist/Padre/doc/perlopref/README /blib/lib/auto/share/dist/Padre/doc/perlopref/perlopref.pod /blib/lib/auto/share/dist/Padre/examples/absolute_beginner/02_time.pl ... I suppose error can be also in Makefile.PL but I didn't find anything strange there. More details can be found at: https://bugzilla.redhat.com/show_bug.cgi?id=557015
  Fri Jan 22 12:55:50 2010 schwern [...] pobox.com - Correspondence added
Subject: Re: [rt.cpan.org #53913] unpackaged blib directories
Date: Fri, 22 Jan 2010 09:55:30 -0800
To: bug-ExtUtils-MakeMaker [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Good archeology about tracking down the change that caused it. Damned if I know why its causing problems. I don't know anything about the RPM build software in question or the significance of the error message. Can you fill that in? And if you could provide a link to the source and maybe some details about what it does maybe it can be puzzled out. My guess is that your software is calling pure_install, and can't handle the all target being run again. Does it, perhaps, mess with the blib directory between running 'make' and running pure_install? -- A: Yes. Show quoted text
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?
  Fri Jan 22 12:55:56 2010 The RT System itself - Status changed from 'new' to 'open'
  Mon Jan 25 11:15:57 2010 mmaslano [...] redhat.com - Correspondence added
From: mmaslano [...] redhat.com
So, I've attached two build logs from creating rpm. RPM is usually calling: make make pure_install PERL_INSTALL_ROOT=%{buildroot} If you make a diff between these two logs, you can see in make section more 'Installing' than before. For example diagram.tt was installed twice. At first in /blib directory and secondly in vendorlib directory. If I try run make && make install manually, I get: [root@X SQL-Translator-0.11003]# make Installing blib/lib/auto/share/dist/SQL-Translator/DiaUml/layer.tt2 Installing blib/lib/auto/share/dist/SQL-Translator/DiaUml/uml-class-start.tt2 Installing blib/lib/auto/share/dist/SQL-Translator/DiaUml/diagram.tt2 ... cp lib/SQL/Translator/Parser/Storable.pm blib/lib/SQL/Translator/Parser/Storable.pm cp lib/SQL/Translator/Filter/DefaultExtra.pm blib/lib/SQL/Translator/Filter/DefaultExtra.pm cp lib/SQL/Translator.pm blib/lib/SQL/Translator.pm ... [root@X SQL-Translator-0.11003]# make install Installing /usr/local/share/perl5/SQL/Translator.pm Installing /usr/local/share/perl5/SQL/Translator/Schema.pm Installing /usr/local/share/perl5/SQL/Translator/Manual.pod Installing /usr/local/share/perl5/SQL/Translator/Diff.pm Installing /usr/local/share/perl5/auto/share/dist/SQL-Translator/DiaUml/layer.tt2 Installing /usr/local/share/perl5/auto/share/dist/SQL-Translator/DiaUml/uml-class-start.tt2 ... I suppose it shouldn't be installing in make part, but I still don't see why it is done and why only for some files in some packages.
Subject: build-pass
Download build-pass
application/octet-stream 42.3k

Message body not shown because it is not plain text.

Subject: build-fail
Download build-fail
application/octet-stream 44.5k

Message body not shown because it is not plain text.

  Mon Jan 25 15:33:32 2010 schwern [...] pobox.com - Correspondence added
Subject: Re: [rt.cpan.org #53913] unpackaged blib directories
Date: Mon, 25 Jan 2010 12:33:01 -0800
To: bug-ExtUtils-MakeMaker [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Marcela Maslanova via RT wrote: Show quoted text
> So, I've attached two build logs from creating rpm. RPM is usually calling: > make > make pure_install PERL_INSTALL_ROOT=%{buildroot} > > If you make a diff between these two logs, you can see in make section > more 'Installing' than before. For example diagram.tt was installed > twice. At first in /blib directory and secondly in vendorlib directory.
SQL::Translator uses Module::Install at which point all bets are off as far as MakeMaker is concerned. I don't know if that's normal behavior or not, you'll have to talk to the Module::Install folks. It is definitely doing an install, rather than a simple copy, into blib. If you have some sort of hook into ExtUtils::Install that would explain it. # Postamble by Module::Install 0.91 config :: $(NOECHO) $(MOD_INSTALL) \ "share" $(INST_LIB)/auto/share/dist/$(DISTNAME) Ok, I think I know what it is, at least for SQL::Translator. Here's the offending line in your build: + make pure_install PERL_INSTALL_ROOT=/root/rpmbuild/BUILDROOT/perl-SQL-Translator-0.11003-1.fc13.i386 You're using PERL_INSTALL_ROOT to talk directly to ExtUtils::Install rather than using DESTDIR to go through MakeMaker. This could have all sorts of side effects. In this case the config target reran (as part of "all") to put things into blib but since PERL_INSTALL_ROOT is set its going into the build root. It should be using DESTDIR. I'd suggest digging back through the change log and seeing why its using PERL_INSTALL_ROOT instead of DESTDIR. Also see if this clears up Padre and DBI::Dumper. -- Don't try the paranormal until you know what's normal. -- "Lords and Ladies" by Terry Prachett
  Fri Feb 05 07:47:45 2010 mmaslano [...] redhat.com - Correspondence added
From: mmaslano [...] redhat.com
Show quoted text
> It should be using DESTDIR. I'd suggest digging back through the > change log > and seeing why its using PERL_INSTALL_ROOT instead of DESTDIR. Also > see if > this clears up Padre and DBI::Dumper. >
DESTDIR fixed problems in some cases. I suppose this change show other problems, which should be fixed. Thank your for your advice. This could be closed.
  Fri Feb 05 17:41:05 2010 mschwern [...] cpan.org - Correspondence added
Thank you for reporting it, its not always easy to know what's a bug and what's a feature in MakeMaker. Hope DESTDIR doesn't mess too many things up.
  Fri Feb 05 17:41:07 2010 mschwern [...] cpan.org - Status changed from 'open' to 'resolved'