Re^3: What's the deal with ExtUtils::MakeMaker [build_requires]

[DStaal]

Something sounds messed up in your system. What's the permissions on MakeMaker.pm and what's your path settings?

[ait]

Thanks for your reply, but the problem is the same in Linux, FreeBSD, and Mac and I run over a dozen workstations and many servers with Catalyst development and they can't all be broken!

People just don't notice it because is a temporary install that's only needed for the build process and many people probably use "follow" for the prereq policy, and hardly ever sit there to actually witness the MakeMaker install every single time you first commence your CPAN shell installs. It even asks you if you want to keep this temporary requirement and even if you say yes, it will temporarily build MakeMaker the next time you use CPAN. Of course, for many people they just don't notice it because it builds fine, it just takes a little extra time, but for those of us who run Perl stuff in chrooted envs like FBSD Jails, do very well notice this, because MakeMaker and similar modules hang on some of the tests, so we usually create FBSD packages in the root server and just copy them over and install them in our jail flavours.

So the only workaround for the FBSD Jail is that every single time you're gonna use the CPAN shell is to first install MakeMaker wait until it hangs on the INSTALL_BASE.t, ˆC, remove that test (using the look shell), and re-run the MakeMaker install, after that you can use that cpan shell session all day. It's a pain, but it works. Besides, I know the module works perfectly because it's built and installed via the pkg system anyway.

There is some evil here that seems to be related to CPAN itself and I'm trying to get to the bottom of this horrible behavior. There is of course another path, and that is to keep hiding this ugly cousin and just figure out why MakeMaker hangs in Jails,but I am hoping for someone to actually come forward and explain the reason why MakeMaker is temporarily built with every single CPAN session. It's like some hardwired dependency.

[DStaal]

I don't run 'follow' as my prereq policy. I have never seen this issue. Including in a test I'm running right now.

You are doing something weird somewhere in you config, that you've managed to replicate out. I have no idea what, but that is not normal behavior.

Edit: It's possible that some module you are using has done an exceptionally bad job of specifying it's requirements, and managed to confuse perl into thinking it wants a newer version of that module, despite it already having the newest version. I'm not exactly sure what type of bug would cause that, but I can see something along that line happening with the mess that is the various different ways to specify version strings in Perl.

[ait]

Yeah, may you're right and this is only related to the stuff we are using, mainly Catalyst and related modules (DBIx::Class, Moose, etc.). Or the particular way we have our set-ups. Guess I'll have to dig deeper....

[merlyn]

This is absolutely, positively, not my experience, and I've been installing CPAN modules since the beginning of the CPAN.

I agree with other responders: something is very broken in your environment.

[djsf]

from ExtUtils/Packlist.pm:207

sub get_dir_list {
        my ($him,@files) = @_;

        my %alldirs;

        for my $file (@files) {
                $file =~ s|/[^/]+$||;
                while (-d $file) {
                        $file =~ s|/([^/]+)$||;
                        my $last = $1;

This loop hangs with $file eq '..' and $last eq 'dummy-install'. This code doesn't check was the regexp substitution successful, and if not, uses $1 from the last time. Change this line to:

 $file =~ s|/([^/]+)$|| or last;

and t/INSTALL_BASE.t will pass the test in a couple of seconds.

[charleso]

For what it works I've been seeing this also. I maintain multiple build environments using FreeBSD, some jailed and some not... and many seem to fall into this state. I've tried to dig into it a few times but have always had other fish to fry (real work). Super annoying. I'll add this... the obsessive reinstalling of ExtUtils::MakeMaker is routine, thought I don't always seem to see the getting-stuck-on-INSTALL_BASE.t behavior.

[djsf]

PS: the reason of this problem is BSDPAN::ExtUtils::Packlist and not ExtUtils::MakeMaker itself.