# from Ken Williams
# on Tuesday 12 June 2007 09:00 pm:
>It's currently exactly analogous to the
>other prereq types, except that during the "dist" action we'll warn
>the author if there's an item in config_requires that isn't present
>in any of the other prereq fields. Earlier today I managed to
>convince myself that might be the right way to do things; I can try
>to lay out my reasoning here if anyone's interested.
In most cases, M::B will be the only c_r entry (and will be auto.) I
would really like to not need to state any explicit M::B requirement in
Build.PL, so then you get into special-casing that automagic entry.
Plus we're only warning the author about it and not covering the
manual-Build.PL scenario.
I think we want to treat missing c_r entries as show-stoppers. That is,
configure_requires => {Module::Build => 0.28} should be analogous to:
use Module::Build 0.28;
We're expecting that CPAN(PLUS) will have already addressed the c_r
assertions or, in the case of a manual-Build.PL operator, they will go
take care of it.
Thus, I think die()ing at Build.PL-time is the thing to do. This means
a different behavior for c_r entries vs any other *_requires entries
(which only warn at Build.PL-time.)
Yes, (Adam) there is an "older CPAN(PLUS)" issue there when you die in
the middle of a big install, but we need to address that elsewhere
(e.g. M::I requires M::B or etc.) If we don't die() when c_r is
unsatisfied, we're risking stranger and less diagnosable failures
elsewhere.
>I haven't figured out the right thing to do vis-a-vis automatically
>adding M::B to config_requires.
We could select some minimum version of Module::Build and bump that as
needed (e.g. "latest official release".) As far as using the value of
Module::Build->VERSION, I'm particularly concerned about what happens
when I'm running a development version of M::B -- I don't want to be
releasing a module that configure_requires a M::B which isn't out yet.
This of course depends on the version-bump policy employed in M::B's
svn (which afaict seems to be bumped at-release rather than
immediately-after-release.)
But in general, we should always use $current. A distro can explicitly
specify an earlier version if they really need to.
--Eric
--
So malloc calls a timeout and starts rummaging around the free chain,
sorting things out, and merging adjacent small free blocks into larger
blocks. This takes 3 1/2 days.
--Joel Spolsky
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------