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

[Glenn L. <pe...@ne...>]

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)

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

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

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

> 
> -- 
> 
> Jos Boumans
> 
>     "If superman is so smart, why does he wear underpants over his  
>     trousers?"
> 
>     CPANPLUS    http://cpanplus.sf.net
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general
> 
> 

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