EDIT: Jenda mentioned that it took a minute before the fact that this applies to OS X clicked, so I've now mentioned this explicitly.

EDIT AGAIN: The Leopard (and Snow Leopard) version is COPYFILE_DISABLE=true

I would have posted this to Q&A, but honestly there's no place to put it there.

Schwern posted me a bug for Date::PeriodParser; seems that the tarfile I uploaded had all these weird '._whatever' files, one for each file in the distribution, and this was causing his install of the module to crash because his build script assumed that anything with a .PL suffix ought to be run - and ._Makefile.PL got included.

Crashing is bad, so I tried to figure out what the problem was. MANIFEST? Nope, that was OK. Weirder: doing a ls -la didn't show any '._' files. Looking on CPAN, though, they were definitely there, so it seemed that it had to be tar adding them. Huh.

A bit of searching found a lot of complaining about these files, plus this incantation:

export COPY_EXTENDED_ATTRIBUTES_DISABLE=true
[download]

If you set this in the shell where you're doing the make dist, tar doesn't add the '._' files.

Apparently, if you fiddle with the files in the Finder (or anything else that wants the files to have a resource fork), tar helpfully adds the '._' files to the tarball; when they're untarred on a Mac, the resource fork gets rebuilt. Anywhere else ends up with '._' files. I had used TextMate to do my last set of edits, so the edit position, etc. was saved in the resource forks, and voila, '._' files.

Ideally, if MakeMaker's Makefile knew to add this to the environment before the tar zcf that builds the distribution tarball. no one would need to remember this anymore, so I'm going to file a requested enhancement to ExtUtils::MakeMaker mentioning this. In the meantime, there's a solution that prevents further problems.