Thank you for such a careful readthrough and the honesty to be critical.

I certainly did not intend this as a 'rebuttal'. The tutorials and all the links you have listed are fine resources and this document simply couldn't have been written without them. They were my starting point, but truth be told, they only underscore my point about either absent or hard to find documentation that brings it all together for 2011.I only mentioned the Perl Monks links specifically because this is, after all, Perl Monks. It was by no means my sole reading list.

• perlnewmod - also only discusses h2xs. It appears this hasn't been updated in years.
• perlmodinstall - this is an excellent article describing how to manually unpack a tarball and install an application. However, it appears to have been written at a point when CPAN.pm was in its infancy.
• perlmodlib - advertises the fact of CPAN and list all of the mirrors and discusses the modulelist. It also has a brief section on module design and naming conventions. It does not describe CPAN meta data, nor the client tools that a released package needs to work with (i.e. CPAN.pm and CPANPlus.pm). Again, it appears that the main body of text was written at a time when CPAN served primarily as a tarball repository from which people manually downloaded.
• perlmod - an excellent article, but it discusses modules as a language element rather than the process of creating and distributing new ones.

If by more comprehensive, you mean more in depth discussion about the module itself, my neglect of their excellent words on that matter was intentional.

Many tutorials on distributing modules have a rather significant section dedicated to module design and coding conventions. I deliberately left such things out unless they affected the actual distribution and testing process. First, module design is a huge topic and one close to my heart. It isn't something I would want to treat lightly. Second, there are many excellent resources devoted to this topic. Third and most importantly, the purpose of this document is not to cool the heels of an over-eager newbie. I assume my target audience is someone who knows programming and Perl itself fairly well, but doesn't know publishing Perl modules well. Distributing bundles for clients is not exactly the same thing as preparing packages to play nicely with CPAN and CPAN.pm

That being said, I think this tutorial would benefit from a "see also" section that would include many of the links you listed. There are links scattered through the tutorial itself, but there are many more not mentioned, some of which you listed above. A few of the links you mention should have also been included in the body of the tutorial. Thanks for the reminder.

make has been a prerequisite to build ...

Perhaps you are reacting to the word "inherently"? I think that might have been a bit too strong, as it implies unsolvability. It is a solvable portability problem, though not necessarily for a novice and not necessarily for all users on a system.

As I understand it make does not ship with all installations of Perl and CPAN.pm does not automatically require it. Not all users build their Perl from scratch so the fact that one needs make to build Perl or XS modules is not really relevant to someone who has installed a pre-build binary Perl interpreter and just wants to download Perl only modules from CPAN.

Some system administrators, even in Linux land, restrict access to or even remove tools typically used for binary compilation (make, cc) for security reasons.

In a CB discussion on this issue this AM (for me, PM for those in the US), there seemed to be mixed feelings about make and portability. Some CPAN clients (there is more than one) will auto-download make/nmake/etc for you if a make like tool is missing. Module::Install is one such client. Some distributions like Strawberry Perl ship with a make-ish tool (dmake I think). Some clients (older CPAN.pm modules) will just bomb if make is missing. For non-novice users there is also the possibility of running perl with the -V:make option.

You can, of course, gain control over the tools and environment used to build your package by bundling software or declaring your preferred tools as pre-requisite. For example, if you want to benefit from Module::Install 's auto-download features, you would need to do that because it isn't core. But there are those who don't like packages that magically install unexpected software, so that option has to be considered carefully as well. One advantage of tools like Module::Build is that it has been in the core since Perl 5.9 and so requires no extra pre-requisites or bundling.