Re: [Module::Build] Archive::Tar file format

[Randy W. S. <Ra...@Th...>]

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.

>>> 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.

>> 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
> 
> 
> 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.