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
