2

I created some proprietary Perl modules I can't share so I put them into a local "darkpan" with orepan2. Here is the beginning of 02packages.details.txt.

[~] $ gunzip -c darkpan/modules/02packages.details.txt.gz
File:         02packages.details.txt
URL:          http://www.perl.com/CPAN/modules/02packages.details.txt
Description:  DarkPAN
Columns:      package name, version, path
Intended-For: Automated fetch routines, namespace documentation.
Written-By:   OrePAN2 0.47
Line-Count:   30
Last-Updated: Wed Apr 24 15:44:46 2019

MyProj::MyMod            1.201904241840         D/DU/DUMMY/MyProj-MyMod-v1.20190424.1840.tar.gz

When I type 

cpanm --mirror=file:///path/to/darkpan --mirror-only MyProj::MyMod

it responds that MyProj::MyMod is up-to-date even though the version in darktab is newer. To get it to install, I have to say "MyProj::MyMod-201904241840" on the command line.

Why won't cpanm recognize that the version in the darkpan index is newer than the one installed?

Why can't I just say

cpanm --mirror=file:///path/to/darkpan --mirror-only MyProj-MyMod

in order to load this as a module and not a single package?

Lawrence I. Siden
  • 9,191
  • 10
  • 43
  • 56
  • I don't have anything helpful to say, except that I also use orepan2, and it works as advertised for me. This sounds crazy, but have you tried something with a shorter version string? Your tarball name indicates a version of v1.20190424.1840, but the version in the index is 1.201904241840. If your version is being truncated, that would explain what you're experiencing. – Diab Jerius Apr 25 '19 at 17:03
  • See also [Is it possible to add multiple versions of a module to a minicpan index?](https://stackoverflow.com/q/54768605/2173773) – Håkon Hægland Apr 25 '19 at 17:08
  • @DiabJerius, I'm pretty sure the version in the file name isn't used at all. The CPAN indexer grabs the version from within the archive and puts it in `02packages.details.txt`, as orepan2 emulated. – ikegami Apr 25 '19 at 19:51
  • @ikegami I'm assuming that the version in the filename is the same as what's in the archive (that's actually question for @LawrenceISiden), so if it differs from what's in the index, that might be an indication that the indexer is somehow mangling it. – Diab Jerius Apr 26 '19 at 13:14
  • @ikegami [ran out of edit time] Without knowing the version in the archive, I'm using the version on the filename as a proxy for it. – Diab Jerius Apr 26 '19 at 13:21
  • In the top-level module, the latest is "$MyProj::MyMod::VERSION = 'v1.20190426.1432';" So the indexer drops the initial 'v' and the second '.' I need to learn more about the version naming rules. – Lawrence I. Siden Apr 26 '19 at 15:19
  • I tried again, removing the initial 'v' from the version number, since I learned that it's unconventional. Still doesn't work without "cpanm --mirror /path/to/my/darkpan --mirror-only MyProj::MyModule@1.xxx.yyy". Notice that I have to give a package name "X::Y", not a dist name "X-Y". How does cpan look up a dist in the index? – Lawrence I. Siden Apr 26 '19 at 16:13
  • I've had no problem with versions with a 'v'. What are the exact versions of the installed and darkpan packages? – Diab Jerius Apr 26 '19 at 17:20
  • I got it to work my using vanilla versioning schema. Example: "$My::Package::VERSION = '1.004'. Then I don't have to specify version number on command line for cpanm to find latest. This is what Dist::Zilla::Plugin::PkgVersion emits by default. – Lawrence I. Siden May 14 '19 at 17:04

1 Answers1

-1

as far as I know, cpanm is right, ‘up-to-dateness’ is based on the fact that something is installed that fits the minimal version specified... which you didn’t. correct me if i’m wrong, but there is a reinstall option that would do the trick and get any latest it can find

vanHoesel
  • 956
  • 9
  • 22
  • No, it's the message given when asked to install a module and the latest version is already installed. It world otherwise install the latest version – ikegami Apr 25 '19 at 19:50