13. Add a post_depends set
Proposal:
Permit specifying of packages that should be installed to provide part of a
packages functionality, but should be installed/built *after* the package
is installed. (kentnl)
Comments:
* Being able to specify package that should be installed after the current
15. Add development_requires
Proposal:
The development_requires field should specify all prerequisites only needed
during development. For example this could include templating or other
preprocessing modules needed to generate the final source. (Slaven Rezic)
Comments:
* This would be just
16. Binary Package Dependencies
Proposal:
Add a binary dependency keyword to be optionally resolved by the shell. eg.
binary_requires:
- linux-debian:
libgif4-dev: 4.1.6
- linux-ubuntu:
libgif4-dev: 4.1.6
- linux-redhat:
giflib-devel: 4.1.6
- freebsd-ports:
28. Short description
Proposal:
Field for short description that can be used in search (with higher
priority than long description), when generating README, OS packages or
submitting dist to Ohloh, Freshmeat and similar sites. 'abstract' currently
is module-specific (for ex. for Shipwright: Best
29. Language
Proposal:
Perl 6 is coming. Some code in Perl 6 is already being uploaded to the
CPAN. A new language field is an important part of the structure we need
to allow Perl 6 to reuse the existing CPAN rather than to try to reinvent
the whole thing. My recommendation would be that this
31. Version changes
Proposal:
Description of changes in that versions and tags for changes. Useful for
submission to Freshmeat and for quick review of changes. --Chorny 18:51, 30
September 2009 (BST)
* David Golden xda...@gmail.com [2009-10-09T07:43:56]
05. Schema
Proposal:
The META spec should come along with a formal schema definition.
(SlavenRezic)
No strong feelings. Not a bad idea. I believe an Rx schema for 1.4 exists.
--
rjbs
* David Golden xda...@gmail.com [2009-10-09T07:45:22]
07. Enhance granularity of prerequisites
Agreed. Also suggest (08. Extensibly Group Prereqs) as related and useful.
--
rjbs
* David Golden xda...@gmail.com [2009-10-09T07:47:00]
10. Add a free-text prerequisite field
Strongly oppose. The META file is meant to tell machines about dists. This
will not be useful.
--
rjbs
* David Golden xda...@gmail.com [2009-10-09T07:47:57]
12. Allow Sequences (Arrays) for Prereqs
Strongly agreed. (I believe I proposed this.)
--
rjbs
Excerpts from David Golden's message of Fri Oct 09 07:47:00 -0400 2009:
10. Add a free-text prerequisite field
Proposal:
Add free-text entries that *describe* prerequisites that cannot be
described right now, like prerequisite: a working libexpat, Need a perl
with defined-or, Need root
Excerpts from David Golden's message of Fri Oct 09 07:53:50 -0400 2009:
26. Specify a DLSIP resource
Proposal:
DLSIP codes should be specified in META.* as a resource.
My impression of DLSIP is that it's nearly as unused as the modules list. Is
this inaccurate?
hdp.
Excerpts from David Golden's message of Fri Oct 09 07:47:57 -0400 2009:
12. Allow Sequences (Arrays) for Prereqs
Proposal:
Right now, to the best of my knowledge, the only benefit of a the magic
Bundle:: namespace is that its prerequisites can be declared in optimal
installation order.
Excerpts from David Golden's message of Fri Oct 09 07:51:29 -0400 2009:
20. Make bugtracker resource a hash
Proposal:
The bugtracker resource shoudl be made into a hash that defines different
types of resources, e.g. web page, email report address, etc. (#toolchain
discussion)
Agree,
* David Golden xda...@gmail.com [2009-10-09T07:48:25]
13. Add a post_depends set
Proposal:
Permit specifying of packages that should be installed to provide part of a
packages functionality, but should be installed/built *after* the package
is installed. (kentnl)
No vote. I'm
* David Golden xda...@gmail.com [2009-10-09T07:48:50]
14. Prerequisites should be mutually exclusive
No vote, no strong opinion.
--
rjbs
* David Golden xda...@gmail.com [2009-10-09T07:49:15]
15. Add development_requires
Proposal:
The development_requires field should specify all prerequisites only needed
during development. For example this could include templating or other
preprocessing modules needed to generate the
* David Golden xda...@gmail.com [2009-10-09T07:51:06]
19. Make repository resource a hash
[Note, a separate Make repository more machine readable proposal
has been merged into this one.]
Agreed.
--
rjbs
* David Golden xda...@gmail.com [2009-10-09T07:52:22]
22. Clarify author field
Proposal:
I would like to see some clarification of what an author is, especially
since the numbers of distros
Agreed.
* I think there are two things you want to know about the distribution: who
to
* David Golden xda...@gmail.com [2009-10-09T07:52:45]
23. Have a development version flag
Agreed.
* Con: Development version'ness would not be determinable post-installation
AdamKennedy
Packlist 2.0?
--
rjbs
* David Golden xda...@gmail.com [2009-10-09T07:54:51]
29. Language
Proposal:
Perl 6 is coming. Some code in Perl 6 is already being uploaded to the
CPAN. A new language field is an important part of the structure we need
to allow Perl 6 to reuse the existing CPAN rather than to try to
* David Golden xda...@gmail.com [2009-10-09T07:56:24]
33. Install Meta files and make them queryable
Proposal: Using something like .packlist or File::ShareDir, the Meta file
should be installed along with the distribution and Meta tools should allow
easy querying of meta information for
On Oct 9, 2009, at 7:11 AM, Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:42:06]
02. Formally switch to YAML Tiny
Proposal:
Change the language referring to YAML to instead refer to YAML
Tiny and
update the specification URL to point to the YAML Tiny specification.
On Oct 9, 2009, at 7:11 AM, Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:42:35]
03. Deprecate YAML Tiny dialect for JSON
Strongly agree.
* I would like one violation of the JSON spec: allow Javascript-style
comments. My one beef with the JSON spec. Elliot
On Oct 9, 2009, at 7:12 AM, Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:43:00]
04. Formalize allowed version number formats
Proposal:
Formalize the spec for version numbers as decimal or normalized
dotted-integer (leading v and at least 3 components). (Dagolden)
On Fri, Oct 9, 2009 at 8:11 AM, Ricardo Signes
perl.cpanw...@rjbs.manxome.org wrote:
* David Golden xda...@gmail.com [2009-10-09T07:42:35]
03. Deprecate YAML Tiny dialect for JSON
Strongly agree.
* I would like one violation of the JSON spec: allow Javascript-style
comments. My one beef
On Oct 9, 2009, at 6:46 AM, David Golden wrote:
09. Clarify intent of 'recommends' and add 'suggests'
Proposal:
The 'recommends' flag is not equivalent to Debian recommends. The
intent
should be made clear for authors and the toolchain. If the Debian
definitions are adopted to better
Excerpts from Graham Barr's message of Fri Oct 09 09:43:42 -0400 2009:
one option could be though that the failure for a recommended dependency to
install could still allow the dependent to install
On one hand, maybe this would be useful for things that e.g. offer a mod_perl
interface, and
On Oct 9, 2009, at 6:48 AM, David Golden wrote:
13. Add a post_depends set
Proposal:
Permit specifying of packages that should be installed to provide
part of a
packages functionality, but should be installed/built *after* the
package
is installed. (kentnl)
I hate circular
On Fri, Oct 9, 2009 at 7:44 AM, David Golden xda...@gmail.com wrote:
06. Data structures, not YAML
Proposal:
The META spec should be defined in terms of (Perl) data structures, and not
in terms of YAML. (Slaven Rezic)
Comments:
* This does not mean that I want to replace YAML by a Perl
On Fri, Oct 9, 2009 at 8:16 AM, Ricardo Signes
perl.cpanw...@rjbs.manxome.org wrote:
* David Golden xda...@gmail.com [2009-10-09T07:45:22]
07. Enhance granularity of prerequisites
Agreed. Also suggest (08. Extensibly Group Prereqs) as related and useful.
Agree on both points.
On Oct 9, 2009, at 6:49 AM, David Golden wrote:
15. Add development_requires
Proposal:
The development_requires field should specify all prerequisites only
needed
during development. For example this could include templating or other
preprocessing modules needed to generate the final
On Oct 9, 2009, at 8:12 AM, Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:49:40]
16. Binary Package Dependencies
No vote, but highly dubious that it could be done in a way we won't
regret
later.
I agree.
Graham.
On Fri, Oct 9, 2009 at 7:46 AM, David Golden xda...@gmail.com wrote:
08. Extensibly Group Prereqs
Proposal:
Rather than have 'config_requires' and 'install_requires' and
'signature_requires' and 'build_recommends', have a two-level system. This
requires a small bit of reworking now, but is
Hi all,
David Golden wrote:
01. Update the YAML version declaration
Proposal:
The version declaration for YAML has not been --- #YAML:1.0 for a long
time, update it to the current YAML 1.1 equivalent.
I'm opposed on practical grounds, as we want Meta parsing in the Perl
core
Excerpts from David Golden's message of Fri Oct 09 09:59:22 -0400 2009:
I would like to specify in a usage section what is expected of
downstream parts of the toolchain.
This is probably a good idea for all the proposals.
hdp.
Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:42:06]
02. Formally switch to YAML Tiny
Proposal:
Change the language referring to YAML to instead refer to YAML Tiny and
update the specification URL to point to the YAML Tiny specification.
(AdamKennedy)
Accept with
On Oct 9, 2009, at 6:50 AM, David Golden wrote:
17. Better formalization of license field
Proposal:
Replace the list of strings for the license field with something
extensible and unambiguous. (RicardoSignes)
+1
From the perspective of search.cpan I would like to see it have two
Graham Barr wrote:
On Oct 9, 2009, at 6:43 AM, David Golden wrote:
05. Schema
Proposal:
The META spec should come along with a formal schema definition.
(SlavenRezic)
I am not so much concerned about a formal schema. But an official module
to validate, or purge bad data, would be great.
Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:44:43]
06. Data structures, not YAML
Proposal:
The META spec should be defined in terms of (Perl) data structures, and not
in terms of YAML. (Slaven Rezic)
Agreed, but the spec should be very clear (perhaps, as said, in an
Hans Dieter Pearcey wrote:
Excerpts from David Golden's message of Fri Oct 09 07:47:00 -0400 2009:
10. Add a free-text prerequisite field
Proposal:
Add free-text entries that *describe* prerequisites that cannot be
described right now, like prerequisite: a working libexpat, Need a perl
with
David Golden wrote:
14. Prerequisites should be mutually exclusive
* I think this would remove a certain amount of useful flexibility,
standard light weight META Object modules could easily automate the
production of the merged list. This feels like sacrificing on a
fundamental point to
David Golden wrote:
16. Binary Package Dependencies
If we could get this right, I'd give all my votes for this. I know that
at least Adam and I had been thinking hard about this kind of thing in a
different context a few years back. It's utterly hard to get right if at
all possible.
On Oct 9, 2009, at 8:18 AM, Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:54:13]
27. Long description
Proposal:
Field for long description that can be used in search, when
generating
README, OS packages or submitting dist to Ohloh, Freshmeat and
similar
sites.
David Golden wrote:
19. Make repository resource a hash
+1
Steffen
On Oct 9, 2009, at 8:19 AM, Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:54:35]
28. Short description
Proposal:
Field for short description that can be used in search (with higher
priority than long description), when generating README, OS
packages or
submitting
Hans Dieter Pearcey wrote:
Excerpts from David Golden's message of Fri Oct 09 07:51:29 -0400 2009:
20. Make bugtracker resource a hash
Proposal:
The bugtracker resource shoudl be made into a hash that defines different
types of resources, e.g. web page, email report address, etc. (#toolchain
On Oct 9, 2009, at 8:19 AM, Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:54:51]
29. Language
Proposal:
Perl 6 is coming. Some code in Perl 6 is already being uploaded to
the
CPAN. A new language field is an important part of the structure
we need
to allow Perl 6
David Golden wrote:
21. Formalize optional_features
I've had more hassle than luck with optional features, but since some
people make valid use of it, I'd be (slightly) against removal.
+1 to formalization
Steffen
David Golden wrote:
23. Have a development version flag
* Con: Development version'ness would not be determinable post-installation
AdamKennedy
Correction to my earlier reply: If we have the META info available
*easily* post installation (cf. 33), my vote becomes a +1.
Steffen
On Oct 9, 2009, at 8:20 AM, Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:56:46]
34. Formally reserve keys for private 'in-house' use
Proposal:
For in-house, non-CPAN use, it would be nice to be able to extend
META.yml
to contain extra keys and data, but any
Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:53:28]
25. Controlling test suite runs
Proposal:
The META spec should add flags to indicate that distribution's
tests may be shuffled or run in parallel. (SlavenRezic)
I like the idea in general. I'd just set aside a name
David Golden wrote:
24. Add a release_status field
Obviously supersedes the devel version proposal (23). This would
depend on post installation, easy querying of META information (33).
Steffen
Hans Dieter Pearcey wrote:
Excerpts from David Golden's message of Fri Oct 09 07:53:50 -0400 2009:
26. Specify a DLSIP resource
Proposal:
DLSIP codes should be specified in META.* as a resource.
My impression of DLSIP is that it's nearly as unused as the modules list. Is
this inaccurate?
Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:54:35]
28. Short description
Proposal:
Field for short description that can be used in search (with higher
priority than long description), when generating README, OS packages or
submitting dist to Ohloh, Freshmeat and
* Steffen Mueller nj88ud...@sneakemail.com [2009-10-09T10:04:44]
As for adopting JSON as the default format: What's the chances of
including a full JSON parser in core?
I believe they are good. JSON.pm has no weird prereqs, works admirably, and
the author has no objections.
--
rjbs
Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:54:13]
27. Long description
Proposal:
Field for long description that can be used in search, when generating
README, OS packages or submitting dist to Ohloh, Freshmeat and similar
sites. --Chorny 19:40, 21 September 2009
* Jarkko Hietaniemi j...@iki.fi [2009-10-09T10:11:35]
I really don't think we should have Perl data structures in files
(that means Perl code, right?), because that indicates doing an eval,
and I don't want to eval any more random code off the 'net than
necessary.
Right. We definitely want a
Hans Dieter Pearcey wrote:
Excerpts from David Golden's message of Fri Oct 09 07:55:36 -0400 2009:
31. Version changes
Proposal:
Description of changes in that versions and tags for changes. Useful for
submission to Freshmeat and for quick review of changes. --Chorny 18:51, 30
September 2009
* Hans Dieter Pearcey h...@pobox.com [2009-10-09T08:34:14]
Excerpts from David Golden's message of Fri Oct 09 07:51:29 -0400 2009:
20. Make bugtracker resource a hash
Agree, given a fixed set of keys.
Agreed, exactly so.
--
rjbs
* David Golden xda...@gmail.com [2009-10-09T07:55:12]
30. Trove-Like Categories
Seems like a organizational step backwards.
Opposed.
--
rjbs
* Dieter
This seems like getting people to agree on a machine-readable
changelog format,
which appears only slightly more likely than world peace. Am I
misreading it?
* Graham Barr gb...@pobox.com [2009-10-09T10:36:48]
yeah. I can see the benefit of machine readable changelogs. I am
* David Golden xda...@gmail.com [2009-10-09T07:53:50]
26. Specify a DLSIP resource
Proposal:
DLSIP codes should be specified in META.* as a resource.
Alternte proposal:
DLSIP codes should be deleted from the internet and never discussed again in
polite company.
Opposed.
--
rjbs
Graham Barr wrote:
* David Golden xda...@gmail.com [2009-10-09T07:56:46]
34. Formally reserve keys for private 'in-house' use
personally I dislike the case distinction and would rather switch to
using x- prefixes which are used in so many other places to mean private
extensions
+1
* Steffen Mueller nj88ud...@sneakemail.com [2009-10-09T10:49:40]
We should always keep in mind how information ends up in META.XXX.
Humans should not have to write META stuff. Therefore, the only
moderately sane and established free-form source of information is
module POD. Since that's
Ricardo Signes wrote:
* Steffen Mueller nj88ud...@sneakemail.com [2009-10-09T10:04:44]
As for adopting JSON as the default format: What's the chances of
including a full JSON parser in core?
I believe they are good. JSON.pm has no weird prereqs, works admirably, and
the author has no
* Steffen Mueller nj88ud...@sneakemail.com [2009-10-09T10:54:31]
Ricardo Signes wrote:
Sure, why not?
Because META should be *generated* from other sources. Where should
free-form data come from?
From the same thing that generates the META.yml file. Each dist tool will
presumably have
On Fri, Oct 9, 2009 at 10:13 AM, Steffen Mueller
nj88ud...@sneakemail.com wrote:
Putting human-readable stuff in a file intended primarily for
machine-readability seems of minimal use to me.
I'm in two minds about this. Such a free form field may be useful if you
consider that human-readable
On Fri, Oct 9, 2009 at 7:47 AM, David Golden xda...@gmail.com wrote:
11. OS/arch/platform-specific requirements
Proposal:
I would like to see a way to specify OS-specific requirements. One option
might be to use Devel::CheckOS, which already seems to have a comprehensive
list of supported
On Fri, Oct 9, 2009 at 7:47 AM, David Golden xda...@gmail.com wrote:
12. Allow Sequences (Arrays) for Prereqs
Proposal:
Right now, to the best of my knowledge, the only benefit of a the magic
Bundle:: namespace is that its prerequisites can be declared in optimal
installation order. If
On Fri, Oct 9, 2009 at 7:48 AM, David Golden xda...@gmail.com wrote:
13. Add a post_depends set
Proposal:
Permit specifying of packages that should be installed to provide part of a
packages functionality, but should be installed/built *after* the package
is installed. (kentnl)
Strongly
And contact for security stuff.
On Fri, Oct 9, 2009 at 10:38 AM, Steffen Mueller
nj88ud...@sneakemail.com wrote:
David Golden wrote:
22. Clarify author field
Consider that it's currently, practically used as a contact field. I get
lots of mail that should have gone to a mailing list
On Fri, Oct 09, 2009 at 07:53:28AM -0400, David Golden wrote:
25. Controlling test suite runs
Proposal:
The META spec should add flags to indicate that distribution's
tests may be shuffled or run in parallel. (SlavenRezic)
Doesn't seem to belong in META to me (echoing Adam K's point).
On Fri, Oct 09, 2009 at 09:21:14AM -0400, Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:56:24]
33. Install Meta files and make them queryable
Proposal: Using something like .packlist or File::ShareDir, the Meta file
should be installed along with the distribution
On Fri, Oct 09, 2009 at 08:21:30AM -0400, Hans Dieter Pearcey wrote:
Excerpts from David Golden's message of Fri Oct 09 07:55:12 -0400 2009:
30. Trove-Like Categories
Proposal:
Add Freshmeat.net or SourceForge-like trove categories with topics
programming languages, etc. As opposed
On Oct 9, 2009, at 4:46 AM, David Golden wrote:
* 'recommends' or 'suggests' they both imply (to me) they list
optional
dependencies. Perhaps we could have both, where 'suggests' implies
the
toolchain should ask whether the user wishes to install listed
dependencies, and 'recommends'
On Oct 9, 2009, at 6:36 AM, Graham Barr wrote:
Rather than have 'config_requires' and 'install_requires' and
'signature_requires' and 'build_recommends', have a two-level
system. This
requires a small bit of reworking now, but is easy to extend later
without
adding many top-level keys.
On Oct 9, 2009, at 6:33 AM, Graham Barr wrote:
On Oct 9, 2009, at 7:16 AM, Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:45:22]
07. Enhance granularity of prerequisites
Agreed. Also suggest (08. Extensibly Group Prereqs) as related and
useful.
+1
+1
D
On Oct 9, 2009, at 6:55 AM, Graham Barr wrote:
Modules should only be listed once across all prerequisite
categories.
E.g. a 'requires' module shouldn't be listed in 'test_requires'; a
'configure_requires' module shouldn't be listed in 'build_requires'.
Instead, the spec should define which
On Oct 9, 2009, at 11:53 AM, Ruslan Zakirov wrote:
* There won't need to be a list, apart from perhaps 02packages.
also,
cpan:///package/Software::License::Perl_5 works; it makes it easy to
re-use your own license in a machine-readable way by publishing it
as a
package, and is
On Oct 9, 2009, at 9:11 AM, Jarkko Hietaniemi wrote:
I really don't think we should have Perl data structures in files
(that means Perl code, right?), because that indicates doing an eval,
and I don't want to eval any more random code off the 'net than
necessary.
I strongly agree that we
On Oct 9, 2009, at 4:50 AM, David Golden wrote:
* dynamic_config is confusing because if missing, it defaults to 1.
Further, the default means that META.yml prerequisites are not
definitive and configuration must be run. Making this mandatory
will at
make this confusing flag more
On Oct 9, 2009, at 7:12 AM, Graham Barr wrote:
resources:
repository:
web: http://github.com/2shortplanks/test-time-hires
url: git://github.com/2shortplanks/test-time-hires.git
format: git
type: github
+1
+1, though I think I'd use vcs instead of format.
Best,
On Oct 9, 2009, at 7:33 AM, Steffen Mueller wrote:
I've had more hassle than luck with optional features, but since
some people make valid use of it, I'd be (slightly) against removal.
+1 to formalization
+1 I've stayed away from optional_features because of the hinky extra
library that
On Oct 9, 2009, at 7:20 AM, Graham Barr wrote:
Packlist 2.0?
Agreed.
The main use of development status seems to be control if the
distribution is indexed as the latest released etc. So having a flag
instead of the hackish way we use _ seems a benefit.
+1
David
On Oct 9, 2009, at 8:03 AM, Ricardo Signes wrote:
* Dieter
This seems like getting people to agree on a machine-readable
changelog format,
which appears only slightly more likely than world peace. Am I
misreading it?
* Graham Barr gb...@pobox.com [2009-10-09T10:36:48]
yeah. I can see the
On Oct 9, 2009, at 8:06 AM, Ricardo Signes wrote:
personally I dislike the case distinction and would rather switch to
using x- prefixes which are used in so many other places to mean
private
extensions
I agree, but I also don't like the idea of in this zone of the
struct, case
On Oct 9, 2009, at 6:47 AM, Graham Barr wrote:
I would like to see a way to specify OS-specific requirements. One
option
might be to use Devel::CheckOS, which already seems to have a
comprehensive
list of supported OS names, and have a hash like:
It is hard to make such a list
On Fri, Oct 9, 2009 at 4:19 PM, Ricardo Signes
perl.cpanw...@rjbs.manxome.org wrote:
* David Golden xda...@gmail.com [2009-10-09T07:47:00]
10. Add a free-text prerequisite field
Strongly oppose. The META file is meant to tell machines about dists. This
will not be useful.
Partly disagree.
* David E. Wheeler da...@kineticode.com [2009-10-09T14:18:42]
WTF is dynamic_config?
If dynamic_config is set in your META.yml:
true means you must run Makefile.PL or Build.PL and rely only on its output
false means the META.yml is entirely authoritative
If not given, the default value is
On Fri, Oct 9, 2009 at 6:54 PM, Steffen Mueller
nj88ud...@sneakemail.com wrote:
Ricardo Signes wrote:
* David Golden xda...@gmail.com [2009-10-09T07:54:13]
27. Long description
Proposal:
Field for long description that can be used in search, when generating
README, OS packages or
On Fri, Oct 9, 2009 at 3:47 PM, David Golden xda...@gmail.com wrote:
12. Allow Sequences (Arrays) for Prereqs
[snip]
order by using a sequence of pairs, Bundle's magic could probably be
made obsolete, simplifying the toolchain overall (over a long deprecation
period).
[snip]
Always, thought
* Ruslan Zakirov ruslan.zaki...@gmail.com [2009-10-09T15:28:29]
On Fri, Oct 9, 2009 at 3:47 PM, David Golden xda...@gmail.com wrote:
12. Allow Sequences (Arrays) for Prereqs
[snip]
order by using a sequence of pairs, Bundle's magic could probably be
made obsolete, simplifying the
On Fri, 09 Oct 2009 16:45 +0200, Steffen Mueller
nj88ud...@sneakemail.com wrote:
Hans Dieter Pearcey wrote:
Excerpts from David Golden's message of Fri Oct 09 07:53:50 -0400 2009:
26. Specify a DLSIP resource
Proposal:
DLSIP codes should be specified in META.* as a resource.
My
On Fri, Oct 9, 2009 at 3:31 PM, Ricardo Signes
perl.cpanw...@rjbs.manxome.org wrote:
* Ruslan Zakirov ruslan.zaki...@gmail.com [2009-10-09T15:28:29]
On Fri, Oct 9, 2009 at 3:47 PM, David Golden xda...@gmail.com wrote:
12. Allow Sequences (Arrays) for Prereqs
[snip]
order by using a
On Fri, Oct 9, 2009 at 10:41 AM, Steffen Mueller
nj88ud...@sneakemail.com wrote:
David Golden wrote:
23. Have a development version flag
* Con: Development version'ness would not be determinable
post-installation
AdamKennedy
Correction to my earlier reply: If we have the META info
On Fri, Oct 9, 2009 at 10:25 AM, Steffen Mueller
nj88ud...@sneakemail.com wrote:
David Golden wrote:
15. Add development_requires
The development_requires field should specify all prerequisites only
needed
during development. For example this could include templating or other
preprocessing
On Fri, Oct 9, 2009 at 7:50 AM, David Golden xda...@gmail.com wrote:
17. Better formalization of license field
Proposal:
Replace the list of strings for the license field with something
extensible and unambiguous. (RicardoSignes)
I would prefer to remove the license field entirely.
In the
On Fri, Oct 9, 2009 at 3:19 PM, Ricardo Signes
perl.cpanw...@rjbs.manxome.org wrote:
* David E. Wheeler da...@kineticode.com [2009-10-09T14:18:42]
WTF is dynamic_config?
If dynamic_config is set in your META.yml:
true means you must run Makefile.PL or Build.PL and rely only on its output
On Fri, Oct 9, 2009 at 7:51 AM, David Golden xda...@gmail.com wrote:
19. Make repository resource a hash
resources:
repository:
web: http://github.com/2shortplanks/test-time-hires
url: git://github.com/2shortplanks/test-time-hires.git
format: git
type:
1 - 100 of 126 matches
Mail list logo
