# from Adam Kennedy
# on Tuesday 24 July 2007 04:40 pm:
>Eric Wilhelm wrote:
>> I was thinking it would be a good idea to list outdated CPAN(PLUS)
>> as conflicts using '>=' versions in META.yml. Probably by default.
>Conflicts implies a fatal package clash for this one specific module.
You're right, it was just a thought.
>If CPAN(PLUS) is fatally out of date for a significant subset of CPAN,
>we need to deal with that seperately, without duplicate a ton of
>metadata in the META.yml.
>
>Also, CPAN(PLUS) is (should be) entirely outside the concern of the
>configuration script/phase.
>
>The CPAN client is a layer ABOVE the configure script.
Yes, but we need *some* mechanism for saying "if you're using a client,
it must be able to support installing this module."
What about using the META.yml version number as a compatibility key?
Or, having something in META.yml such as "client_support_version"?
This (of course) doesn't work on the legacy clients, but that's not the
goal here. I'm simply looking for some way to cue clients to update
themselves, which of course requires a self-updating client. (Assuming
that not all clients are "aggressively self-updating", since there
seems to be some resistance to that.)
--Eric
--
"Time flies like an arrow, but fruit flies like a banana."
--Groucho Marx
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
