Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > perl.cpan.workers > #662 > unrolled thread

When cpanm fails to find any of the files in a kit

Back to article view | Back to perl.cpan.workers

Contents

  When cpanm fails to find any of the files in a kit jkeen@verizon.net (James E Keenan) - 2016-09-09 11:17 -0400
    Re: When cpanm fails to find any of the files in a kit zefram@fysh.org (Zefram) - 2016-09-09 16:53 +0100
      Re: When cpanm fails to find any of the files in a kit zefram@fysh.org (Zefram) - 2016-09-09 17:06 +0100

#662 — When cpanm fails to find any of the files in a kit

Today my attention was drawn to this older post on Stack Overflow:

http://stackoverflow.com/questions/37009887/cpanm-perl-module-installation-failed-on-make-and-make-test

The original poster apparently found a work-around for his problem, but 
I felt there were still puzzling things about the case.  Here's the 
setup (as best I can tell):

1. User has installed App::cpanminus to work with the system perl.

2. User tries to use cpanm to install a module (in this case, Try::Tiny, 
but it doesn't really matter which one) from CPAN.  It appears that, at 
least on the user's first pass he/she did not use 'sudo' in any way -- 
but the actual command-line invocation is not provided.

3. cpanm first sounds warnings at:

#####
Checking if your kit is complete...
Warning: the following files are missing in your kit:
         lib/Try/Tiny.pm
         maint/bench.pl
         t/00-report-prereqs.dd
...
#####

The process appears to be failing *all* the files in the kit; this is 
not a problem of a CPAN author screwing up one or two items in the MANIFEST.

That's what puzzling to me:  The fact that cpanm (or perhaps 'make' 
underneath cpanm) is missing the kit in its entirety.

Have others encountered this?

Do you know what could have caused this?  (The poster apparently got a 
better outcome when using 'sudo' with 'cpanm', but it's not clear to me 
why that would happen.)

Thank you very much.
Jim Keenan

[toc] | [next] | [standalone]

#663

James E Keenan wrote:
>That's what puzzling to me:  The fact that cpanm (or perhaps 'make'
>underneath cpanm) is missing the kit in its entirety.

How does it know which files are missing?  It must have at least access
to the MANIFEST.  The preceding cpanm trace shows that it read META.json,
and since the manifest check comes from Makefile.PL obviously it managed
to run that too.  So those files are definitely actually present.
The test phase also refers to actual files in the t/ subdirectory,
so those are present too.  Most likely all the files are actually present.

Interestingly, the MANIFEST check isn't failing to find *all* files.
Files listed in the MANIFEST that it doesn't complain about are
CONTRIBUTING, Changes, INSTALL, LICENCE, MANIFEST, META.json, META.yml,
Makefile.PL, README, and dist.ini.  The difference, apparently, is that
it finds all the files in the top-level directory, but can't find any
files in subdirectories.

When it comes to the test phase, things get weirder.  The test harness
can find the test scripts in the t/ subdirectory, but perl can't find
the module which should have been installed into blib/lib.  My guess is
that the module has actually not been installed into blib/lib, with the
build step being broken by the same thing that broke the MANIFEST check.

>Do you know what could have caused this?

I'm mystified as to how that could happen.  Need to poke around an
example of it to debug further.

-zefram

[toc] | [prev] | [next] | [standalone]

#664

Having looked at the code for the MANIFEST check, I see that it uses
File::Find to enumerate what's present, and then checks that each item
in the MANIFEST is in the set of files that it found.  So the problem
seems to amount to File::Find failing to recurse into subdirectories.
I suspect that the installation is happening on a filesystem that shows
nlink==2 for all directories, thus misleading File::Find into applying
the no-subdirectories optimisation.

I think the second run, with sudo, went wrong because it was working
from an unclean build directory.  Only the first failure is meaningful.

-zefram

[toc] | [prev] | [standalone]

Back to top | Article view | perl.cpan.workers

csiph-web