> On Dec 31, 2017, at 07:25, Henk P. Penning wrote:
>
>
> I don't see how such a change can be kept local ;
> how can it /not/ propagate to downstream mirrors?
If the JSON file was named using the mirror hostname then index.html can
extract the name from the URL and it wouldn’t matter if the
On Wed, Jul 26, 2000 at 12:35:39PM -0500, Elaine -HFB- Ashton wrote:
> While I'm thinking about it I thought I'd post the URL for the OSD spec.
>
> http://www.w3.org/TR/NOTE-OSD
>
> While reading it two things were in question; how will it fit into the
> CPAN
This is TBD. But what I could see i
On Thu, Jul 27, 2000 at 12:46:13PM +0900, Simon Cozens wrote:
> On Wed, Jul 26, 2000 at 11:15:03PM +0300, Jarkko Hietaniemi wrote:
> > On Wed, Jul 26, 2000 at 12:35:39PM -0500, Elaine -HFB- Ashton wrote:
> > > While I'm thinking about it I thought I'd post the URL for the OSD spec.
> > >
> > > ht
On Sat, Jul 29, 2000 at 10:19:36AM +0200, Andreas J. Koenig wrote:
> >>>>> On Thu, 27 Jul 2000 13:13:59 +0100, Graham Barr <[EMAIL PROTECTED]> said:
>
> > On Wed, Jul 26, 2000 at 12:35:39PM -0500, Elaine -HFB- Ashton wrote:
> >> While I'm think
On Sun, Jul 30, 2000 at 10:32:57PM +0200, Andreas J. Koenig wrote:
> Let me withdraw what I said. I think, it's OK as you suggest. But we
> should offer the user the option to not filling in anything into any
> file except into the Makefile.PL and leaving all the work to
> MakeMaker. That way we w
On Tue, Aug 01, 2000 at 04:59:42PM -0400, Chris Nandor wrote:
> At 14:50 -0500 2000.08.01, Elaine -HFB- Ashton wrote:
> >What else would people like to see besides author, email, name, version,
> >url, signature, dependancies???
>
> What about binary distributions?
The OSD supports this. THi
On Tue, Aug 01, 2000 at 02:50:19PM -0500, Elaine -HFB- Ashton wrote:
> Andreas J. Koenig [[EMAIL PROTECTED]] quoth:
> *>- a signature
> *>- a list of namespaces used within the files that are being installed
> *> by this distribution
> *>- a list of version numbers
list of version numbers ? Do y
On Tue, Aug 01, 2000 at 11:07:47PM +0200, Andreas J. Koenig wrote:
> > On Tue, 1 Aug 2000 14:50:19 -0500, [EMAIL PROTECTED] (Elaine M. Ashton)
>said:
>
> > Andreas J. Koenig [[EMAIL PROTECTED]] quoth:
> > *>
> > *>I'm not arguing for changing the format but to optimize it for what we
> >
On Wed, Aug 02, 2000 at 05:06:17PM +0200, Andreas J. Koenig wrote:
> A signature by PAUSE is an interesting idea. But it would tell the
> user something different than a signature by a person. While I imagine
> that a sig by GBARR would mean something like: "I have written or at
> least doublechec
On Wed, Aug 02, 2000 at 07:47:09PM +0200, Andreas J. Koenig wrote:
> > The AUTHOR field is not related to the signature. Actually I would always
> > consider LArry as the author of perl, so I would expectLarry to appear
> > as the AUTHOR in the OSD, unless he said he wanted someother email addr
No directly, but it could be. The only place it exists as a single
thing is in the MySQL database that tester.cpan.org works from.
Graham.
On Mon, May 14, 2001 at 03:27:56PM -0400, Adam Turoff wrote:
> Is the data used for testers.cpan.org available anywhere in one
> comprehensive chunk?
>
>
On Fri, Jun 29, 2001 at 06:43:13PM -0400, Chris Nandor wrote:
> At 08:36 -0400 2001.06.24, Jon Orwant wrote:
> >On Sun, Jun 24, 2001 at 12:28:06AM -0700, Ask Bjoern Hansen wrote:
> >> On Sat, 23 Jun 2001, Elaine -HFB- Ashton wrote:
> >> > btw - Is there anything we can do at TPC for Paul 'the test
Don't you think this should have been discussed with cpan-testers FIRST !!!
As it is I was about to change the script, but this module would not have
been changed.
Graham.
On Sun, Sep 09, 2001 at 10:45:00PM -0400, Kirrily Robert wrote:
> In lists.projects.perl.cpan-workers, you wrote:
> >
> >-
On Mon, Sep 10, 2001 at 12:21:19PM -0400, Kirrily Robert wrote:
> On Mon, Sep 10, 2001 at 08:30:06AM +0100, Graham Barr wrote:
> | Don't you think this should have been discussed with cpan-testers FIRST !!!
>
> Probably. I kinda assumed that Schwern had... oops :(
>
> |
On Oct 9, 2009, at 7:10 AM, Ricardo Signes wrote:
* David Golden [2009-10-09T07:41:35]
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.
Reject. YAML::Tiny for ol
On Oct 9, 2009, at 7:11 AM, Ricardo Signes wrote:
* David Golden [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.
(AdamKenne
On Oct 9, 2009, at 7:11 AM, Ricardo Signes wrote:
* David Golden [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
Strongly disagree. We
On Oct 9, 2009, at 7:12 AM, Ricardo Signes wrote:
* David Golden [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)
Agree. (Wordi
On Oct 9, 2009, at 7:14 AM, Ricardo Signes wrote:
* David Golden [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,
On Oct 9, 2009, at 7:16 AM, Ricardo Signes wrote:
* David Golden [2009-10-09T07:45:22]
07. Enhance granularity of prerequisites
Agreed. Also suggest (08. Extensibly Group Prereqs) as related and
useful.
+1
Graham.
On Oct 9, 2009, at 6:46 AM, David Golden 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 easy to extend later
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. otherwise users end up
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 match
On Oct 9, 2009, at 6:47 AM, David Golden wrote:
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 access to /media/test".
On Oct 9, 2009, at 6:47 AM, David Golden 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 OS names, and have a
On Oct 9, 2009, at 6:47 AM, David Golden 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 META allowed prereqs
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 dependencies
On Oct 9, 2009, at 6:48 AM, David Golden wrote:
14. Prerequisites should be mutually exclusive
Proposal:
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 '
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 sourc
On Oct 9, 2009, at 8:12 AM, Ricardo Signes wrote:
* David Golden [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 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
properti
On Oct 9, 2009, at 6:50 AM, David Golden wrote:
18. Make dynamic_config mandatory
Proposal:
Make the 'dynamic_config' a mandatory field (Dagolden)
* Or rename it to static_config (chorny)
no opinion
Graham.
On Oct 9, 2009, at 6:51 AM, David Golden 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: github
+1
On Oct 9, 2009, at 7:34 AM, 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 r
On Oct 9, 2009, at 8:15 AM, Ricardo Signes wrote:
* David Golden [2009-10-09T07:51:56]
21. Formalize optional_features
Proposal:
Optional features: is supported in META.yml, but it requires a lot of
manual intervention and trickery to make it work. And it is very
poorly
documented. (Tux)
On Oct 9, 2009, at 8:16 AM, Ricardo Signes wrote:
* David Golden [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 abou
On Oct 9, 2009, at 8:17 AM, Ricardo Signes wrote:
* David Golden [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?
Agreed.
The main use of development status see
On Oct 9, 2009, at 6:53 AM, David Golden wrote:
24. Add a "release_status" field
Proposal:
Add a mandatory ''release_status'' field with a limited list of
acceptable
values. E.g. "stable", "testing" and "unstable", with "alpha" as an
alias
for "unstable" and "beta" as an alias for "test
On Oct 9, 2009, at 6:53 AM, 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)
I do not think the META is the right place for this.
It seems something that could
On Oct 9, 2009, at 7:25 AM, 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
On Oct 9, 2009, at 8:18 AM, Ricardo Signes wrote:
* David Golden [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
On Oct 9, 2009, at 8:19 AM, Ricardo Signes wrote:
* David Golden [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, Fres
On Oct 9, 2009, at 8:19 AM, Ricardo Signes wrote:
* David Golden [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 e
On Oct 9, 2009, at 6:55 AM, David Golden wrote:
30. Trove-Like Categories
Proposal:
Add Freshmeat.net or SourceForge-like trove categories with topics
programming languages, etc. As opposed to keywords/labels/tags they
are a
nested tree, and will also be limited to a given list. This will
On Oct 9, 2009, at 7:20 AM, 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. --
On Oct 9, 2009, at 6:56 AM, David Golden wrote:
32. Steal from other package meta specs
Proposal:
Hunt down the spec authors and some heavy package users, ask what in
the
spec/package meta files works for them and what doesn't, then steal
the
best features. -- Daxim
Seems like an ongoi
On Oct 9, 2009, at 7:19 AM, Hans Dieter Pearcey wrote:
Excerpts from David Golden's message of Fri Oct 09 07:56:24 -0400
2009:
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 distrib
On Oct 9, 2009, at 8:20 AM, Ricardo Signes wrote:
* David Golden [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 extensions that we choos
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 namespace
On Oct 9, 2009, at 10:48 AM, Tim Bunce wrote:
On Fri, Oct 09, 2009 at 09:21:14AM -0400, Ricardo Signes wrote:
* David Golden [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 a
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 shoul
On Oct 9, 2009, at 3:21 PM, David Golden wrote:
On Fri, Oct 9, 2009 at 7:51 AM, David Golden 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
for
On Mar 25, 2010, at 8:42 AM, Barbie wrote:
>
> Lastly I would also personnally be annoyed if only the latest versions
> were available, as I often make great use of the diff tool on
> search.cpan.org. Having only the latest version renders that great tool
> redundant :(
I use that too :-) and it
On Apr 14, 2010, at 6:48 AM, Tim Bunce wrote:
>
>> If we separate Perl 5 and Perl 6 distributions within the file system,
>> we can distinguish between them easily and without relying on indexes,
>> meta data files or other elements of complexity.
>
> True, but is that *really* a significant need
On Apr 14, 2010, at 8:18 AM, Jesse Vincent wrote:
> On Wed, Apr 14, 2010 at 06:14:45AM -0700, Ovid wrote:
>> --- On Wed, 14/4/10, Jesse Vincent wrote:
>>
>>> From: Jesse Vincent
>>>
Agreed, but you know you're going to see this and
>>> variants thereof:
requires:
On Apr 28, 2011, at 11:19 , brian d foy wrote:
> On Tue, Feb 8, 2011 at 4:44 AM, Adam Kennedy wrote:
>> I think I may have implemented what you're looking for several years
>> ago for JSAN, which has a client that auto-detected appropriate
>> mirrors in a few seconds each time it starts.
>>
>>
56 matches
Mail list logo
