Ken Williams wrote:
On Mar 6, 2006, at 4:44 PM, Randy W. Sims wrote:
There are a number of problems it could be intended to solve, but I'm
not sure which one(s).
1) For automated builders/testers, it could indicate that a module
requires user intervention. Eg. it queries the user for input during
install.
2) The dependencies listed in META.yml are not static. Maybe a
Win32::* module is required only when run under Windows, but is not
listed in META.yml because there is currently no way to express
conditional dependencies.
3) The description in the spec would seem to imply that a static
config indicates that module can be installed without the builder
(i.e. Module::Build)), that the modules could simply be copied into
the proper folders by any tool. This would mean any module with with
XS or compiled code as well as anything under (1) and (2) above are
dynamic?
I'd intended it as 1 & 2 but not 3. In other words, whether the
information in the META.yml is definitive or not. If it weren't, then
a cautious or curious user might want to read the Build.PL before
installing.
Everything is on the honor system of course, so it's not really a
security thing, just a convenience thing.
Maybe that section could be clarified a bit:
:>>>
(Spec 1.0) [optional] {boolean} A boolean flag indicating that the
content of the META.yml does *not* represent a complete and static
description of the distribution. If the properties of the distribution
as described by META.yml change depending on operating environment or
user choice, this should be set to 1 (true).
For example, if one of the prerequisites this distribution 'requires' is
only needed on BSD flavored platforms, the metadata would be considered
"dynamic", so the 'dynamic_config' field should be set to 1 (true).
If this field is omitted, it defaults to 1 (true).
:<<<
The above with other clarifications and corrections you've made could
maybe be a 1.2.1 release maybe?
And/Or with the following a 1.3 release:
The alternative listed under "recommends" should probably be removed or
made an official part of the spec.
The repository field could be constructed as a mapping:
repository:
type: cvs
location: :pserver:[EMAIL PROTECTED]:/cvsroot/module-build
or possibly some type of (icky) compound field:
repository: [svn] https://svn.versiondude.net/randys/CPAN-Metadata
Randy.
