# 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
--
"It is impossible to make anything foolproof because fools are so
ingenious."
--Murphy's Second Corollary
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
