It's been mentioned several times, and at the Perl 5 Day it was discussed further. I've been muddling this over for a while, seeing as the number of distributions that hit a brick wall are gently increasing during my CPAN testing. However, although the packaging seems fairly straight forward, well okay that's not quite true, otherwise it would have been done years ago, but it crossed my mind how to version number this thing?
SDK-Perl-5.6.1_1.tar.gz SDK-Perl-5.6.1-1.tar.gz SDK-Perl-5.6.1-1.0.tar.gz SDK-Perl-5-6-1-1.0.tar.gz [a] SDK-Perl-5-6-1-5.8.7.tar.gz [b] SDK-Perl-5-006001-5.8.7.tar.gz SDK-Perl5-006001-5.8.7.tar.gz SDK-Perl5006001-5.8.7.tar.gz [c]
I'm favouring [a], but [b] might be clearer, although [c] wouldn't confuse the current apps that use CPAN, such as CPAN.pm, CPANPLUS, CPAN-YACSmoke, CPANTS and the WWW-CPAN-Testers-Generator. Bearing in mind that as a current set I would be thinking of something like:
SDK-Perl5006001-5.8.7.tar.gz SDK-Perl5008000-5.8.7.tar.gz SDK-Perl5008001-5.8.7.tar.gz [*] SDK-Perl5008002-5.8.7.tar.gz [*] SDK-Perl5008003-5.8.7.tar.gz [*] SDK-Perl5008004-5.8.7.tar.gz SDK-Perl5008005-5.8.7.tar.gz [*] SDK-Perl5008006-5.8.7.tar.gz SDK-Perl5008007-5.8.7.tar.gz [d]
Regarding the ones marked [*], I haven't seen these versions of Perl being used, but are there for completeness sake :) The contents would only contain those versions of modules that have been upgraded from the base install and are applicable to the version of Perl to which the SDK is associated with. I've included [d] as a placeholder, as this would initially include no modules but perhaps just a POD file to explain why it's there.
Taking this further, a rule could then be potentially included within an installer, that if it noted that a particular distribution required perl-5.8.7, it could then automatically check for the SDK for the version of Perl currently installed. So for example on my test box it would then check for SDK-Perl5006001-5.8.7.tar.gz. Knowing CPANPLUS, this would be possible, but I don't know about CPAN.pm.
In the assembly line for these SDKs, I'd be looking at using Module::CoreList and Perl::MinimumVersion, together with an automated script to copy the modules and tests into the appropriate SDK directories. It would then be a matter of running an automated test suite over all the SDKs, running 'make dist' on each if they're okay, and calling cpan-upload. Well it sounds simple .....
I'm putting thoughts here really so I don't forget them, that they're publically available to disassemble and come up with better ideas, or for someone who has more time on their hands to try for themselves and see what works and what doesn't. With my current workload I doubt I'll get to play with this properly this year, but at least I have something to refer back to now :)
I was going to post the above a few weeks ago, but then I decided to present it as a lightning talk at the Birmingham.pm technical meeting last night. I knew it might generate a bit of discussion so I ensured it was the last talk of the night. I was right.
It was mooted whether the modules shouldn't just be uploaded to CPAN anyway, but that would mean I'd be uploading them and not P5P who are the real maintainers. I didn't like that idea. However, there is certainly no harm in creating a local repository that people could reference if they didn't want to use the SDKs. It would require a bit more work to package the modules into a distribution, but it's possible. Note that this would only need to be applied to those modules which aren't actively maintained outside of the core, such as ExtUtils::MakeMaker.
It was also questioned whether the SDK shouldn't just include all the modules from the base install, including those that hadn't been upgraded. While I'm certainly entertaining that idea, I was initially reluctant to have duplication of code. On reflection this might be worthwhile doing if there ever comes a point when the perl distribution only includes essentials modules and uses the SDK to install the recommended extras. But what would constitute an essential module? Dynaloader and strict were obvious choices, but it could get tricky. In fact the whole thing is still tricky!
I'm going to have a bit more thought on this over the next month and see whether I can see a reasonable way to implement this, without causing holy wars and an albatross around my neck.
Note: Slides were built to work in Firefox, if they don't work in your browser, then I'm willing to accept patches ;)
