Re: META version

The idea with METALOCAL would be that the META.yml would contain the 
regular set of requires/build_requires, but that if the configure script 
was able to tell that it was configuring with a supported CPAN client, 
it would generate it in separate build_requires/test_requires instead.

The other alternative is the server-driven toolchain approach.

Basically, we'd make a file on the server that contained the minimum 
supported toolchain.

The CPAN client would pull this file at the same time as the index to 
validate that it had a new enough version of the toolchain.

If not, it would upgrade itself before trying to install anything.

Adam K

Eric Wilhelm wrote:
> # from Adam Kennedy
> # on Tuesday 20 May 2008:
>
>   
>> That said, it's possible that we might be able to fix this problem
>> with METALOCAL.yml...
>>     
>
> I'm failing to see the target along that trajectory.  If METALOCAL is 
> created on the client machine, it is subject to compatibility error.  
> Further, it won't even be created by old tools, so the META.yml has to 
> contain all of the compatibility.
>
> I see the root of these issues as being in the client tools -- they 
> never had any way to know when they become broken.  If we bump the 
> META.yml spec in a way that leads to breakage with older tools, we need 
> to be able to declare something like "build_requires META::Support $v" 
> or else breakage happens in strange and non-obvious ways.
>
> Perhaps the "META::Support" module could even check old versions of 
> CPAN/CPANPLUS and force them to upgrade or at least break with a nice 
> error -- that is: if the toolchain isn't using META::Support, depending 
> on it doesn't work.
>
> This doesn't *strictly* require a module, but it does require some way 
> to predictably fail when the toolchain is old and broken.
>
> I'll quietly continue lobbying for deprecation (and then removal) of 
> 02packages.detail.txt.gz...
>
> --Eric
>