Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the CPAN-Meta CPAN distribution.

Report information
The Basics
Id: 74755
Status: resolved
Priority: 0/
Queue: CPAN-Meta
People
Owner: Nobody in particular
Requestors: dagolden [...] cpan.org
thaljef [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Tue Feb 07 16:17:28 2012 dagolden [...] cpan.org - Ticket created
Subject: spec: provides does not account for generated files
The spec for 'provides' assumes static files existing in the distribution root. This does not account for module files which are generated at build-time, such as from (non-Makemaker/Build.PL files). (E.g. 'Foo.PL' which generates 'blib/lib/Foo.pm' for installation) Should the spec be revised to suggest that the path of the 'file' subfield is relative to 'blib' instead of to the root directory of the distribution? That has the advantage of making the 'file' subfield certain to match where ExtUtils::Install actually installs stuff.
  Tue Apr 09 17:08:00 2013 thaljef [...] cpan.org - Ticket #84537: Ticket created
Subject: Must provided files exist?
The spec says the "file" attribute for provided packages is required. But the spec is vague on whether that file must actually exist. Usually it does, but there are some distributions that generate packages at build-time. If such distributions want to help the indexer by declaring the provided packages, then what should the "file" attribute be in that case?
  Wed Apr 10 10:31:35 2013 dagolden [...] cpan.org - Ticket #84537: Correspondence added
Subject: Re: [rt.cpan.org #84537] Must provided files exist?
Date: Wed, 10 Apr 2013 10:30:50 -0400
To: bug-CPAN-Meta [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
It's not worded well for dealing with generated packages. On the one hand, you could put the post-build path that would be generated. On the other hand, you could put the source file that has the actual code doing the generation. I'm not sure that anything actually uses this field. We should clarifying this one way or the other. On Tue, Apr 9, 2013 at 5:08 PM, Jeffrey Ryan Thalhammer via RT <bug-CPAN-Meta@rt.cpan.org> wrote: Show quoted text
> Tue Apr 09 17:08:00 2013: Request 84537 was acted upon. > Transaction: Ticket created by THALJEF > Queue: CPAN-Meta > Subject: Must provided files exist? > Broken in: 2.101090 > Severity: Normal > Owner: Nobody > Requestors: thaljef@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84537 > > > > The spec says the "file" attribute for provided packages is required. But the spec is vague on whether that file must actually exist. Usually it does, but there are some distributions that generate packages at build-time. If such distributions want to help the indexer by declaring the provided packages, then what should the "file" attribute be in that case?
-- David Golden <dagolden@cpan.org> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
  Wed Apr 10 10:31:36 2013 The RT System itself - Ticket #84537: Status changed from 'new' to 'open'
  Wed Apr 10 11:39:38 2013 thaljef [...] cpan.org - Ticket #84537: Correspondence added
Show quoted text
> I'm not sure that anything actually uses this
Well, I'm using it to compute SHA digests for every .pm file in the distribution. My goal is to provide a map from files back to distributions (similar to Dist::Surveyor). Show quoted text
> We should clarifying this one way or the other.
Yes please. In my (non-expert) view, the META is intended to be a static source of information about a distribution. So whatever it says ought be true in a static context (i.e. before running any kind of configuration or build). So perhaps there could be something like a boolean "dynamic_file" attribute that is an alternative to the "file" attribute for each provided package (you could have one or the other, but not both). That could signal to META consumers that the distribution does provide a certain package but it does not have a static manifestation yet. Just my 2 cents.
  Wed Apr 10 11:49:41 2013 dagolden [...] cpan.org - Ticket #84537: Correspondence added
Subject: Re: [rt.cpan.org #84537] Must provided files exist?
Date: Wed, 10 Apr 2013 11:48:55 -0400
To: bug-CPAN-Meta [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
You realize that mapping isn't necessarily unique, right? On Wed, Apr 10, 2013 at 11:39 AM, Jeffrey Ryan Thalhammer via RT <bug-CPAN-Meta@rt.cpan.org> wrote: Show quoted text
> Queue: CPAN-Meta > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=84537 > >
>> I'm not sure that anything actually uses this
> > Well, I'm using it to compute SHA digests for every .pm file in the distribution. My goal is to provide a map from files back to distributions (similar to Dist::Surveyor). >
>> We should clarifying this one way or the other.
> > Yes please. In my (non-expert) view, the META is intended to be a static source of information about a distribution. So whatever it says ought be true in a static context (i.e. before running any kind of configuration or build). > > So perhaps there could be something like a boolean "dynamic_file" attribute that is an alternative to the "file" attribute for each provided package (you could have one or the other, but not both). That could signal to META consumers that the distribution does provide a certain package but it does not have a static manifestation yet. > > Just my 2 cents.
-- David Golden <dagolden@cpan.org> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
  Wed Apr 10 11:55:25 2013 thaljef [...] cpan.org - Ticket #84537: Correspondence added
Show quoted text
> You realize that mapping isn't necessarily unique, right?
Yes, I realize that. It's an imprecise process. Sometimes you have to pick the best among several incomplete or duplicate mappings.
  Fri Apr 12 01:11:34 2013 dagolden [...] cpan.org - Ticket #84537: Merged into ticket #74755
  Fri Apr 12 01:11:34 2013 dagolden [...] cpan.org - Merged into ticket #74755
  Sat Apr 13 15:15:39 2013 dagolden [...] cpan.org - Correspondence added
Decision at the Lancaster Consensus is that this field must be a file in the distribution directory -- either the .pm file *or* another file that generates the package. I've patched the repo and will release it "soon" to clarify that.
  Sat Apr 13 15:15:39 2013 dagolden [...] cpan.org - Status changed from 'new' to 'resolved'