Re: [Module::Build] Archive::Tar file format
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
Re: [Module::Build] Archive::Tar file format
|
From: Glenn L. <pe...@ne...> - 2004-01-08 02:50:50
|
On approximately 1/7/2004 4:10 PM, came the following characters from the keyboard of Randy W. Sims: > On 1/7/2004 5:47 PM, Glenn Linderman wrote: > >> On approximately 1/7/2004 1:08 AM, came the following characters from >> the keyboard of Jos I. Boumans: >> >>> >>> On 7-jan-04, at 3:35, Glenn Linderman wrote: >>> >>>> The way I see things, after installing the A::T 1.07 on Windows >>>> (hadn't notice 1.08 yet, Randy has sharp eyes!), I would use M::B >>>> to build a module's .tar.gz and .ppd file, and then there were 3 >>>> symptoms, that may or may not be related. >>>> >>>> 1) During the build of the .tar.gz, warnings were printed about not >>>> being able to add directory entries to the archive. >>> >>> >>> >>> by A::T? if so, can you provide me with a test case? >> >> >> >> Using Win2K SP4, M::B 21_02, A::T 1.07 (latest with PPDs in my >> repository list) > > > If the ppm archives are not up to date yet, and you don't have a make > tool, grab A::T 1.08 from CPAN.org and put the attached 'Build.PL' in > the root distribution dir, and you should be able to use it to install. > >> Unzip the attached (Actually, I'll send it to you privately), will >> create \GFfP directory structure. >> >> cd \GFfP >> perl build.pl >> perl build >> perl build dist >> >> Warnings from the last command are: >> >> d:\GFfP>perl build dist >> perl build dist >> Unable to add file: 'GFfP-0.1' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Unable to add file: 'GFfP-0.1/blib' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Unable to add file: 'GFfP-0.1/blib/lib' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Unable to add file: 'GFfP-0.1/blib/arch' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Unable to add file: 'GFfP-0.1/blib/arch/auto' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Unable to add file: 'GFfP-0.1/blib/arch/auto/GFfP' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Deleting META.yml >> Creating GFfP-0.1.tar.gz >> Deleting GFfP-0.1 > > > This is fixed in 1.08. OK, I've installed Archive::Tar 1.08, and confirmed that I no longer get the warnings above. >>>> 2) Most TAR decoding programs cannot see the PATH data, although >>>> the latest GNU TAR can >>> >>> >>> >>> yes, apparently (especially on windows) there's many clients that >>> follow an old(er) spec. Although i am still of the same opinion that >>> these clients are just inherintly broken, I do have a thought on how >>> we may be able to amend this; >>> >>> Can one of you who had trouble with the extracting confirm that when >>> extracting this tarball >>> >>> http://search.cpan.org/CPAN/authors/id/K/KA/KAKE/Bot-BasicBot- >>> Pluggable-Module-SimpleBlog-0.02.tar.gz >> >> >> >> Well, interesting. >> >> PowerArchiver 2001 can usually ungzip and untar in one operation. But >> not this file. But by first doing ungzip in PowerArchiver, and then >> reopening the resulting .tar file in PowerArchiver, then the paths are >> visible. > > > I tested with WinZip 8.1 and WinRAR 3.20 and both worked, I had forgot > you had mentioned the problem occuring in PowerArchiver. Yep, well it seems pretty clear that PowerArchiver is truncating names longer than 100 chars. But my module's .tar.gz doesn't have names longer than 100 chars. But PowerArchiver still can't see the pathnames for my module, not even when built with A::T 1.08 (previous test was with 1.07). >>> everything actually goes as expected, and that a file named >>> >>> Bot-BasicBot-Pluggable-Module-SimpleBlog-0.02/lib/Bot/BasicBot/ >>> Pluggable/Module/SimpleBlog/Store/SQLite.pm >>> >>> is living in the extracted directory? >> >> >> >> In the extracted directory, at the location specified, there is a file >> named "SQ" which seems to contain what you would expect to find in a >> file named SQLite.pm . So it appears that PowerArchiver 2001 length >> limits the extraction path name to a length of 100 bytes. >> >> However, the "unxutils" version of TAR can extract it, some other >> ancient NT port of TAR can extract it. GNU TAR 1.12 can extract it. >> >> None of these latter three utilities can extract the path names of the >> .tar.gz build for the attached module, by A::T 1.07 (nor can >> PowerArchiver 2001). >> >>> If so, we could use the ././@LongLink extended tar format solution, >>> which is >>> really meant to be used for paths > 255 chars, but will work equally >>> well for >>> our purposes here... i'd equip A::T with a special flag that would >>> trigger the >>> use of ././@LongLink files at anything over >100 chars, rather than >>> at >255, >>> thus avoiding the use of the PREFIX header, and thus (hopefully) >>> solving your >>> problems :) >> >> >> >> As far as avoiding the problems, I don't think any of my paths are >> greater than 100 chars. They are less. But still not seen by the >> above mentioned 4 programs. >> >>>> 3) PPM claims to install the module, but nothing actually gets >>>> installed. M::B can install the module fine from the source >>>> directory. Given the other symptoms, it seems like it can't find >>>> the files in the archive, but it reports no errors. >>> >>> >>> >>> not much i can do with this one Randy... It looks like M::B 0.21_02 is still building PPD files that PPM dislikes: "Error: no suitable installation target found for package GFfP." So I still have to manually edit the PPD file to fix this. Maybe this one got dropped through the cracks of all the other problems? After hand editing the PPD file, this time around PPM install GFfP.ppd again claimed to installe GFfP, but only one file was listed during the install (hey, that's better than none, like last time around): ppm> install GFfP.ppd ==================== Install 'GFfP' version 0.1 in ActivePerl 5.8.0.805. ==================== Downloaded 7356 bytes. Extracting 14/14: GFfP-0.1/blib/arch/auto/GFfP/GFfP.lib Successfully installed GFfP version 0.1 in ActivePerl 5.8.0.805. And? It didn't actually install anything, not even that one file. So it still seems to me like PPM is getting confused by a funny .tar.gz file. Or something. >> Well, if PPM is using A::T to do extraction (I believe it is), and I >> am using A::T to do archiving (I believe M::B is, on my behalf), and >> PPM cannot extract the files because of a either a change in A::T >> interface, or a change in A::T file format, then perhaps you can, as >> you maintain A::T. On the other hand, if PPM is misusing A::T, then >> you probably can't. >> >> I really don't know where the problem is, for this one, but if we can >> get the first two issues resolved, then we will have a better >> foundation on which to analyze this third issue. And get the PPM >> folks involved if needed. But it is hard to point the finger at PPM >> at the moment, since (1) It hasn't changed (on my machine, at least) >> (2) It unpacks lots of other stuff (3) just the .tar.gz package build >> by M::B and A::T seem to give it problems. > > > Randy. > > > > > ------------------------------------------------------------------------ > > use Module::Build; > > use strict; > use warnings; > > my $have_zlib = eval { require IO::Zlib; 1 }; > > unless( $have_zlib ) { > warn <<EOM; > You do not have IO::Zlib installed. This means you can not read > or write compressed archives! > EOM > } > > Module::Build->new( > module_name => 'Module::Build', > dist_author => 'Jos Boumans <kane[at]cpan.org>', > dist_abstract => 'Manipulates TAR archives', > dist_version_from => 'lib/Archive/Tar.pm', > license => 'perl', > > requires => { > 'perl' => '5.005_03', > 'File::Spec' => 0.82, > }, > recommends => { > 'IO::Zlib' => 0, > }, > build_requires => { > 'Test::More' => 0, > 'Test::Harness' => 2.26, > }, > )->create_build_script(); > -- Glenn -- http://nevcal.com/ =========================== The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing. |
