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

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

On approximately 1/6/2004 5:16 PM, came the following characters from
the keyboard of Randy W. Sims:

> On 12/20/2003 5:23 PM, Jos I. Boumans wrote:
> 
>>
>> On Sat, 20 Dec 2003, Ken Williams wrote:
>>
>>> On Saturday, December 20, 2003, at 12:17  PM, Randy W. Sims wrote:
>>>
>>>> Well this atleast proves that the paths are there, thus it is not a
>>>> problem with M::B, but I think this is going to be a big issue for
>>>> Windows users. I think if it's possible for Archive::Tar to be better
>>>> compatible with other tools, it should. If I knew anything about the
>>>> tar  format, I'd try to provide a patch. Since I don't, I'll just cc
>>>> the maintainer. ;-)
>>>
>>>
>>> I have some kind of vague recollection that maybe this issue in
>>> Archive::Tar has been fixed privately by Kane and is just waiting for
>>> him to release it.
>>>
>>> Kane, can you put Glenn out of his misery?  Or am I remembering wrong?
>>
>>
>>
>> well, even though m::b may use A::T to build an archive, and ppm uses it
>> to extract, it may not be the same A::T -- AS perl ships with a very old
>> version of A::T which does not support the full tar standard (including
>> the prefix header). Several people have already advised AS to upgrade 
>> A::T
>> to a recent version, that works on win32 and actually supports most of 
>> the
>> spec...
>>
>> the easiest fix would be to require the client to have a::t > 1.00 to 
>> make
>> sure this doesn't happen, but i'm not sure how to enforce this...
> 
> 
> Hi Jos,
> 
> I just saw that A::T 1.08 hit CPAN and was very quick to try it out. 
> It's looking a lot better since you've taken over maintenance on it, and 
> more specifically this latest release has fixed some annoying problems 
> on Win32. However the above problem is unfortunately still present. I've 
> verified that using this latest version to create an archive does not 
> solve the problem with most Windows utilities being unable to read the 
> path information in the archive. This problem does not occur with 
> archive created with GNU tar. As this problem has been reported several 
> times on the M::B mailing list (and is apparently becoming a critical 
> issue for Win32 M::B users), I'm afraid this problem is going to 
> continue to plague us unless we can find a resolution. If I knew 
> anything of the tar format I'd submit a patch--Is there anything I can 
> do to help resolve this issue.
> 
> Thanks,
> Randy.

Right.  Thanks Randy for following up on this, I was just wondering 
again today if anything had happened in the last couple weeks (of course 
it is hard to get computer time during the holidays!).

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.

2) Most TAR decoding programs cannot see the PATH data, although the 
latest GNU TAR can

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.

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