Bug #36798 for PPM-Make: PROVIDE elements in ppd file have wrong version number

Mon Jun 16 05:22:37 2008 albers [...] cpan.org - Ticket created

Subject:

PROVIDE elements in ppd file have wrong version number

When I prepare a new release for a module with make_ppm, the versions in the SOFTPKG and PROVIDE elements in the ppm file differ. The value of the VERSION attribute of the SOFTPKG element has the expected value extracted from the module as demanded by VERSION_FROM in Makefile.PM. The VERSION attributes of the various PROVIDE elements however contain the previous module versions, apparently extracted from the configured ppm repositories or CPAN (no version of the module was installed when the distribution was created). Instead, the current versions should be extracted from the files and placed here. The module in question is Config::LotusNotes. To reproduce, just change $VERSION in the two module files and the two primary test files to a higher value. Attached is a ppd file constructed under these circumstances ($VERSION set to 33 where the public version is 32). Platform: ActivePerl 5.8.10 on Windows XP.

Subject:

Config-LotusNotes.ppd

Download Config-LotusNotes.ppd
application/octet-stream 691b

Message body not shown because it is not plain text.

Sun Jan 04 19:50:53 2009 RKOBES [...] cpan.org - Correspondence added

On Mon Jun 16 05:22:37 2008, ALBERS wrote: Show quoted text

> When I prepare a new release for a module with make_ppm, the versions in > the SOFTPKG and PROVIDE elements in the ppm file differ. > > The value of the VERSION attribute of the SOFTPKG element has the > expected value extracted from the module as demanded by VERSION_FROM in > Makefile.PM. > > The VERSION attributes of the various PROVIDE elements however contain > the previous module versions, apparently extracted from the configured > ppm repositories or CPAN (no version of the module was installed when > the distribution was created). Instead, the current versions should be > extracted from the files and placed here. > > The module in question is Config::LotusNotes. To reproduce, just change > $VERSION in the two module files and the two primary test files to a > higher value. Attached is a ppd file constructed under these > circumstances ($VERSION set to 33 where the public version is 32). > > Platform: ActivePerl 5.8.10 on Windows XP.

Sorry for the delay on this. You're right in surmising that the mismatch occurs because the module version info is extracted from a remote database. The reason for doing this is that this information has been filtered through the PAUSE checks for consistency, and I want this information to be consistent with the CPAN indices (eg, sometimes CPAN distributions contain module files with one version number and a META.yml file containing a different version). I could run through the same checks that PAUSE does, but I have to make a remote database call anyway for some information that isn't in the CPAN distribution - mapping module to distribution names - so I might as well get the module version information at the same time.

Sun Jan 04 19:50:54 2009 The RT System itself - Status changed from 'new' to 'open'

Thu Sep 10 13:03:35 2009 dolmen [...] cpan.org - Correspondence added

Did you check your META.yml content? make_ppm uses this data to generate the PPD. If META.yml is not up to date, you should simply update it: Module::Build: Build distmeta ExtUtils::MakeMaker: make metafile

Thu Sep 10 13:19:08 2009 dolmen [...] cpan.org - Correspondence added

Looks like I'm wrong. PPM::Make does not use the META.yml Le Dim. Jan. 04 19:50:53 2009, RKOBES a écrit : Show quoted text

> Sorry for the delay on this. You're right in surmising that the mismatch > occurs because the module version info is extracted from a remote > database. The reason for doing this is that this information has been > filtered through the PAUSE checks for consistency, and I want this > information to be consistent with the CPAN indices (eg, sometimes CPAN > distributions contain module files with one version number and a > META.yml file containing a different version). I could run through the > same checks that PAUSE does, but I have to make a remote database call > anyway for some information that isn't in the CPAN distribution - > mapping module to distribution names - so I might as well get the module > version information at the same time.

The problem with this approach is that I can not use PPM::Make to create PPD for darkpan modules, as it does not find "Provides". As Module::Build PPM generation is outdated I can not currently build a PPM for darkpan Module::Build based distributions.

Mon Sep 14 15:31:36 2009 albers [...] cpan.org - Correspondence added

Show quoted text

> The reason for doing this is that this information has been > filtered through the PAUSE checks for consistency, and I want this > information to be consistent with the CPAN indices (eg, sometimes CPAN > distributions contain module files with one version number and a > META.yml file containing a different version).

I disagree: Favouring version information from a remote database over the data contained in the local files will introduce another source of inconsistency. There definitely are legal use cases where local and remote versions differ: a) having to install an outdated version of a module b) preparing a new release of a CPAN module c) if there is no CPAN release for your module (see dolmen's posting) Maybe documenting the version retrieval strategy and providing a way to circumvent it by means of a new command line switch like "favour local version information over CPAN versions" or "disable remote version lookups" could help here.

Sat Sep 19 20:16:30 2009 RKOBES [...] cpan.org - Correspondence added

I like the idea of disabling remote lookups of information; this has been added to http://github.com/rkobes/ppm-make, which will be uploaded to CPAN soon.

Sat Sep 19 20:16:31 2009 RKOBES [...] cpan.org - Status changed from 'open' to 'resolved'