[rt.cpan.org #104635] IO error the first time an executable built by the packer is run on OSX

Mon Jun 29 15:49:22 2015: Request 104635 was acted upon.
Transaction: Correspondence added by RSCHUPP
       Queue: PAR-Packer
     Subject: IO error the first time an executable built by the packer is run on OSX
   Broken in: 1.025
    Severity: (no value)
       Owner: RSCHUPP
  Requestors: [email protected]
      Status: open
 Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=104635 >


On 2015-06-26 04:56:15, RSCHUPP wrote:
> OK, time for some code exegesis...

Perhaps the bug is not in PAR::Packer, but rather in Module::ScanDeps 
(which is used by PAR::Packer to determine what modules etc to "pack in").

$ scandeps.pl -V eg/foo
# Foo.pm [module]
# Foo/Bar.pm [module]
# foo [data]                  <--- ???
# Legend: [C]ore [X]ternal [S]ubmodule [?]NotOnCPAN
'Foo::Bar' => '0', #    ? # Foo
'Foo'      => '0', #    ? # foo

But when I move foo to the cwd:

$ scandeps.pl -V foo
# Foo.pm [module]
# Foo/Bar.pm [module]
# Legend: [C]ore [X]ternal [S]ubmodule [?]NotOnCPAN
'Foo::Bar' => '0', #    ? # Foo
'Foo'      => '0', #    ? # foo

also

$ scandeps.pl -V ./foo
# Foo.pm [module]
# Foo/Bar.pm [module]
# foo [data]            <--- ???
# Legend: [C]ore [X]ternal [S]ubmodule [?]NotOnCPAN
'Foo::Bar' => '0', #    ? # Foo
'Foo'      => '0', #    ? # foo

The line "# foo [data]" is probably responsible for the spurious zip member lib/foo:

$ pp -o good.exe foo
$ unzip -l good.exe
Archive:  good.exe
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2015-06-29 21:42   lib/
        0  2015-06-29 21:42   script/
      455  2015-06-29 21:42   MANIFEST
      215  2015-06-29 21:42   META.yml
       80  2015-06-29 21:42   lib/Foo.pm
       71  2015-06-29 21:42   lib/Foo/Bar.pm
       55  2015-06-29 21:42   script/foo
      676  2015-06-29 21:42   script/main.pl
---------                     -------
     1552                     8 files

Note: no lib/foo!
To be continued.

Cheers, Roderich