Skip Menu |

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

Report information
The Basics
Id: 46807
Status: rejected
Priority: 0/
Queue: ExtUtils-MakeMaker

People
Owner: Nobody in particular
Requestors: admin [...] photoresearchers.com
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in:
  • 6.50
  • 6.52
Fixed in: (no value)



Subject: PREFIX? rpmbuild writes to wrong location
I had a RHEL3 box with an old version of ExtUtils::MakeMaker (6.03) that I wanted to upgrade. However the newest version(s) 6.52 and 6.50 and perhaps further back than that are dangerously incompatible with this system due to the fact that the PREFIX is no longer being used properly by rpmbuild. I tried to build an rpm from a source of SpamAssassin (spamassassin.apache.org) using the newly upgraded version of ExtUtils::MakeMaker and it started writing to the *live* install directories rather than the destination in /var/tmp/. This had worked properly with the older version of ExtUtils::MakeMaker, so I know that the problem lies with that upgrade, unless it's simply not backward compatible with older spec files and I don't know where this would be documented. Notice where it goes wrong: Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.41625 + umask 022 + cd /usr/src/redhat/BUILD + cd Mail-SpamAssassin-3.1.9 + LANG=C + export LANG + unset DISPLAY + '[' /var/tmp/spamassassin-root '!=' / ']' + rm -rf /var/tmp/spamassassin-root + make prefix=/var/tmp/spamassassin-root/usr exec_prefix=/var/tmp/spamassassin-root/usr bindir=/var/tmp/spamassassin-root/usr/bin sbindir=/var/tmp/spamassassin-root/usr/sbin sysconfdir=/var/tmp/spamassassin-root/etc datadir=/var/tmp/spamassassin-root/usr/share includedir=/var/tmp/spamassassin-root/usr/include libdir=/var/tmp/spamassassin-root/usr/lib libexecdir=/var/tmp/spamassassin-root/usr/libexec localstatedir=/var/tmp/spamassassin-root/var sharedstatedir=/var/tmp/spamassassin-root/usr/com mandir=/var/tmp/spamassassin-root/usr/share/man infodir=/var/tmp/spamassassin-root/usr/share/info install INSTALLMAN1DIR=/usr/share/man/man1 INSTALLMAN3DIR=/usr/share/man/man3 INSTALLSITEMAN1DIR=/usr/share/man/man1 INSTALLSITEMAN3DIR=/usr/share/man/man3 INSTALLVENDORMAN1DIR=/usr/share/man/man1 INSTALLVENDORMAN3DIR=/usr/share/man/man3 Installing ...<snip> Appending installation info to /var/tmp/spamassassin-root/usr/lib/perl5/5.8.0/i386-linux-thread-multi/perllocal.pod /usr/bin/perl "-MExtUtils::Command" -e mkpath /etc/mail/spamassassin <snip> /usr/bin/perl "-MExtUtils::Command" -e mkpath /usr/share/spamassassin /usr/bin/perl -e "map unlink, </usr/share/spamassassin/*>" /usr/bin/perl build/preprocessor -Mvars -DVERSION="3.001009" -DPREFIX="/usr" -DDEF_RULES_DIR="/usr/share/spamassassin" -DLOCAL_RULES_DIR="/etc/mail/spamassassin" -DLOCAL_STATE_DIR="/var/lib/spamassassin" -DINSTALLSITELIB="/usr/lib/perl5/site_perl/5.8.0" -DCONTACT_ADDRESS="the administrator of that system" -m644 -Irules -O/usr/share/spamassassin 10_misc.cf [...] chmod 755 /usr/share/spamassassin + install -d /var/tmp/spamassassin-root//etc/rc.d/init.d + install -d /var/tmp/spamassassin-root//usr/include + install -m 0755 spamd/redhat-rc-script.sh /var/tmp/spamassassin-root//etc/rc.d/init.d/spamassassin + /bin/mv spamd/README spamd/README.spamd + mkdir -p /var/tmp/spamassassin-root/etc/mail/spamassassin <snip> Processing files: perl-Mail-SpamAssassin-3.1.9-1 error: File not found: /var/tmp/spamassassin-root/usr/share/spamassassin This is of course where the build dies. When attempted with the older version of MakeMaker, it proceeded in a similar manner but maintaining the correct PREFIX. This is the expected behavior: Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.27877 + umask 022 + cd /usr/src/redhat/BUILD + cd Mail-SpamAssassin-3.1.9 + LANG=C + export LANG + unset DISPLAY + '[' /var/tmp/spamassassin-root '!=' / ']' + rm -rf /var/tmp/spamassassin-root + make prefix=/var/tmp/spamassassin-root/usr exec_prefix=/var/tmp/spamassassin-root/usr bindir=/var/tmp/spamassassin-root/usr/bin sbindir=/var/tmp/spamassassin-root/usr/sbin sysconfdir=/var/tmp/spamassassin-root/etc datadir=/var/tmp/spamassassin-root/usr/share includedir=/var/tmp/spamassassin-root/usr/include libdir=/var/tmp/spamassassin-root/usr/lib libexecdir=/var/tmp/spamassassin-root/usr/libexec localstatedir=/var/tmp/spamassassin-root/var sharedstatedir=/var/tmp/spamassassin-root/usr/com mandir=/var/tmp/spamassassin-root/usr/share/man infodir=/var/tmp/spamassassin-root/usr/share/info install INSTALLMAN1DIR=/usr/share/man/man1 INSTALLMAN3DIR=/usr/share/man/man3 INSTALLSITEMAN1DIR=/usr/share/man/man1 INSTALLSITEMAN3DIR=/usr/share/man/man3 INSTALLVENDORMAN1DIR=/usr/share/man/man1 INSTALLVENDORMAN3DIR=/usr/share/man/man3 Installing ...<snip> Writing /var/tmp/spamassassin-root/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Mail/SpamAssassin/.packlist Appending installation info to /var/tmp/spamassassin-root/usr/lib/perl5/5.8.0/i386-linux-thread-multi/perllocal.pod /usr/bin/perl "-MExtUtils::Command" -e mkpath /var/tmp/spamassassin-root/etc/mail/spamassassin <snip> /usr/bin/perl "-MExtUtils::Command" -e mkpath /var/tmp/spamassassin-root/usr/share/spamassassin /usr/bin/perl -e "map unlink, </var/tmp/spamassassin-root/usr/share/spamassassin/*>" /usr/bin/perl build/preprocessor -Mvars -DVERSION="3.001009" -DPREFIX="/usr" -DDEF_RULES_DIR="/usr/share/spamassassin" -DLOCAL_RULES_DIR="/etc/mail/spamassassin" -DLOCAL_STATE_DIR="/var/lib/spamassassin" -DINSTALLSITELIB="/usr/lib/perl5/site_perl/5.8.0" -DCONTACT_ADDRESS="the administrator of that system" -m644 -Irules -O/var/tmp/spamassassin-root/usr/share/spamassassin 10_misc.cf [...] chmod 755 /var/tmp/spamassassin-root/usr/share/spamassassin + install -d /var/tmp/spamassassin-root//etc/rc.d/init.d + install -d /var/tmp/spamassassin-root//usr/include + install -m 0755 spamd/redhat-rc-script.sh /var/tmp/spamassassin-root//etc/rc.d/init.d/spamassassin + /bin/mv spamd/README spamd/README.spamd + mkdir -p /var/tmp/spamassassin-root/etc/mail/spamassassin <snip> Processing files: spamassassin-3.1.9-1 Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.31039 + umask 022 + cd /usr/src/redhat/BUILD + cd Mail-SpamAssassin-3.1.9 + DOCDIR=/var/tmp/spamassassin-root/usr/share/doc/spamassassin-3.1.9 + export DOCDIR + rm -rf /var/tmp/spamassassin-root/usr/share/doc/spamassassin-3.1.9 + /bin/mkdir -p /var/tmp/spamassassin-root/usr/share/doc/spamassassin-3.1.9 + cp -pr README Changes sample-nonspam.txt sample-spam.txt spamd/README.spamd INSTALL BUGS LICENSE TRADEMARK USAGE sql UPGRADE /var/tmp/spamassassin-root/usr/share/doc/spamassassin-3.1.9 + exit 0 What is the version that introduced this change in behavior, and where lies the fault? If there is an incompatibility it is not well-documented. And it shouldn't be the case that newer versions of MakeMaker would break rpmbuild in this manner.
Subject: Re: [rt.cpan.org #46807] PREFIX? rpmbuild writes to wrong location
Date: Tue, 09 Jun 2009 12:27:20 -0700
To: bug-ExtUtils-MakeMaker [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Administrator via RT wrote: Show quoted text
> I had a RHEL3 box
Holy cats! Show quoted text
> with an old version of ExtUtils::MakeMaker (6.03) that > I wanted to upgrade. However the newest version(s) 6.52 and 6.50 and > perhaps further back than that are dangerously incompatible with this > system due to the fact that the PREFIX is no longer being used properly > by rpmbuild. I tried to build an rpm from a source of SpamAssassin > (spamassassin.apache.org) using the newly upgraded version of > ExtUtils::MakeMaker and it started writing to the *live* install > directories rather than the destination in /var/tmp/. This had worked > properly with the older version of ExtUtils::MakeMaker, so I know that > the problem lies with that upgrade, unless it's simply not backward > compatible with older spec files and I don't know where this would be > documented.
Nothing obvious has changed to break PREFIX. But Spamassassin's Makefile.PL is over a thousand lines long. It is known to do some unspeakable things to MakeMaker including using un/vaguely documented features. This is going to be fun to track down. Also PREFIX is unpredictable (by unfortunate design) and it should be using INSTALL_BASE when possible (which acts like what everyone else calls --prefix). But that's another story. Show quoted text
> Notice where it goes wrong:
Without knowing what got passed into MakeMaker there's no way of knowing what went wrong or where. If you would please attach the top level MakeMaker generated Makefile then we can start tracking this down. It should start with something like: # This Makefile is for the Mail::SpamAssassin extension to perl. # # It was generated automatically by MakeMaker version # 6.53_02 (Revision: 65302) from the contents of # Makefile.PL. Don't edit this file, edit Makefile.PL instead. -- ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml
Show quoted text
> If you would please attach the top level MakeMaker > generated Makefile then we can start tracking this > down. It should start with something like: > > # This Makefile is for the Mail::SpamAssassin extension to perl. > # > # It was generated automatically by MakeMaker version > # 6.53_02 (Revision: 65302) from the contents of > # Makefile.PL. Don't edit this file, edit Makefile.PL instead.
Here is the Makefile generated with 6.50. I can try it with 6.53_02 if you'd like, but my guess is that the cause of this problem will be common to all the latest versions.
Download Makefile-6.50
application/octet-stream 58.9k

Message body not shown because it is not plain text.

Show quoted text
> Here is the Makefile generated with 6.50.
I'm not that great at reading Makefiles, for what it's worth, but comparing it to an older generated version, I think the problem stems from the B_DATADIR variable (and B_CONFDIR, B_LIBDIR, etc.). In the old version I_DATADIR is set to $(INSTALLSITEDATA) and B_DATADIR to $(DESTINSTALLSITEDATA). With the newer versions of MakeMaker, I_DATADIR is set the same way, but B_DATADIR is set to $(I_DATADIR) rather than $(DESTINSTALLSITEDATA). I don't know what causes that to happen, but I think it gets closer to the specific problem.
Subject: Re: [rt.cpan.org #46807] PREFIX? rpmbuild writes to wrong location
Date: Tue, 09 Jun 2009 15:16:23 -0700
To: bug-ExtUtils-MakeMaker [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Administrator via RT wrote: Show quoted text
> Queue: ExtUtils-MakeMaker > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=46807 > >
>> If you would please attach the top level MakeMaker >> generated Makefile then we can start tracking this >> down. It should start with something like: >> >> # This Makefile is for the Mail::SpamAssassin extension to perl. >> # >> # It was generated automatically by MakeMaker version >> # 6.53_02 (Revision: 65302) from the contents of >> # Makefile.PL. Don't edit this file, edit Makefile.PL instead.
> > Here is the Makefile generated with 6.50. I can try it with 6.53_02 if > you'd like, but my guess is that the cause of this problem will be > common to all the latest versions.
Short version: Its a spamassassin bug. I'll forward this on to them. Long version: An initial scan looks good. Its setting PREFIX=/usr and a DESTDIR=/var/tmp/spamassassin-root as it should. This means its being built to run from /usr but is actually being copied into /var/tmp/spamassassin-root/usr. This is how rpm normally builds packages. Upon closer inspection of your error message, I don't think the problem lies with MakeMaker: Processing files: perl-Mail-SpamAssassin-3.1.9-1 error: File not found: /var/tmp/spamassassin-root/usr/share/spamassassin Its trying to install into /var/tmp/spamassassin-root as it should, but something did not create the necessary directories. I suspect what's happened is something in Spamassassin is only looking at the PREFIX and not the DESTDIR. So special magic Spamassassin code which is doing its own install is sticking stuff straight into PREFIX. Here's the suspicious entry in their Makefile: MM_HAS_DESTDIR = no MM_HAS_GOOD_DESTDIR = yes MM_KNOWS_DESTDIR = no MM_NEEDS_DESTDIR = no MakeMaker has a "good" DESTDIR but doesn't have it and doesn't know it? Que? The problem, as suspected, is Spamassassin mucking with MakeMaker guts which have since changed, as they will. Here it is in their Makefile.PL # MakeMaker prior to 6.11 doesn't support DESTDIR which is needed for # packaging with builddir!=destdir. See bug 2388. $mm_knows_destdir = $ExtUtils::MakeMaker::Recognized_Att_Keys{DESTDIR}; $mm_has_good_destdir = $mm_version >= 6.11; # Add DESTDIR hack only if it's requested (and necessary) $mm_needs_destdir = $opt{'destdir'} && !$mm_has_good_destdir; $mm_has_destdir = $mm_knows_destdir || $mm_needs_destdir; push(@ATT_KEYS, 'DESTDIR') if $mm_needs_destdir; # Now make EU::MM understand our extended vars foreach my $key (@ATT_KEYS) { $ExtUtils::MakeMaker::Recognized_Att_Keys{$key} = 1; } %ExtUtils::MakeMaker::Recognized_Att_Keys is a private MakeMaker variable. It happened to be declared as a global. Now it is lexical and thus unreadable. This change was made at the end of 2007 as part of 6.44. There's supposed to be a warning about this, but the logic (above) is broken and quite overcomplicated. It should just check the MakeMaker version and leave it at that. Or just set configure_requires for a new version of MakeMaker and not try to work around 12 years of bugs (just 4 or 5 maybe). -- THIS I COMMAND!