Skip Menu |
 

This queue is for tickets about the App-FatPacker CPAN distribution.

Report information
The Basics
Id: 57811
Status: resolved
Priority: 0/
Queue: App-FatPacker

People
Owner: ether [...] cpan.org
Requestors: CHOCOLATE [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: (no value)
Fixed in: 0.009012



Subject: Packed scripts don't work on perls < 5.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 1329
Download (untitled) / with headers
text/plain 1.2k
Hi. Just spotted this while trying to use cpanminus on perl 5.6.2 - it dies complaining that it can't find one of the packed files (App/cpanminus/script.pm). The problem occurs in the @INC hook sub. In-memory files were only introduced in 5.8.0 (according to the docs for open). If this line: open my $fh, '<', \$fat; is changed to: open my $fh, '<', \$fat or die "can't open fatpacked $_[1]: $!"; it dies with: Can't open fatpacked App/cpanminus/script.pm: No such file or directory at cpanm line 5621. Not sure what the best solution is. IO::String looks like the smallest module that backports string filehandles (all the way back to 5.005_03). Maybe pack that as well (possibly trimming out its write methods) in a %fatpack_runtime or %fatpack_dependencies hash (in case any more are needed)? It's not exactly a moving target (last updated in 2005). Or perhaps add a --target or --min-version option to fatpack so that it's only packed on request? On a similar note, lexical filehandles were only introduced in 5.6 (according to perlfaq5), so ideally that "open my..." would need to be tweaked as well for maximum backward-compatibility. Perhaps just trim the fat from IO::String and use it in all cases? e.g. return IO::String->new($fat) or: return FatPack::Handle->new($fat); chocolateboy
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-6782-1274774061-692.57811-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 87
FYI: there's more discussion here: http://github.com/miyagawa/cpanminus/issues#issue/46
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-6782-1274774061-692.57811-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <rt-3.8.HEAD-6782-1274774061-692.57811-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-29446-1348113405-1955.57811-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 51
How important is it to maintain support for <5.8.0?
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-29446-1348113405-1955.57811-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <rt-3.8.HEAD-6782-1274774061-692.57811-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-29446-1348113405-1955.57811-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-30281-1356149919-1363.57811-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 181
Download (untitled) / with headers
text/plain 181b
On Wed Sep 19 20:56:45 2012, ETHER wrote: Show quoted text
> How important is it to maintain support for <5.8.0?
I'm bumping the minimum to 5.8.0 for now in git until we figure out what to do here.
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-6028-1358539241-1085.57811-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 68
0.009012 released with a patch for <5.8 perls. Please give it a try!


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.