Re: [Module::Build] codebase? paths in .tar.gz?

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

On approximately 12/21/2003 4:18 AM, came the following characters from
the keyboard of Andrew Savige:
> --- "Randy W. Sims" <Ra...@Th...> wrote:
> 
>>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,
>>
>>Actually this problem is occuring in recent versions of Archive::Tar; In 
>>fact, it happens with a post 1.07 snapshot Andrew referred me to a while 
>>back when we were having other problems (warnings when directories are 
>>added to the tar). If Ken can confirm that he used 'perl Build dist' to 
>>create the 'Module-Build-0.21_01.tar.gz' dist currently on CPAN and that 
>>he used a recent version of Archive::Tar, I think that will narrow down 
>>the problem to something in the way tar files are created on Windows as 
>>opposed to other OSs. When I look at that dist in WinZip (one of the 
>>common programs on windows used to handle tar files), the directory 
>>structure is there. When I untar that dist and run 'perl Build dist' in 
>>it, the tar file created on Windows does not show the directory 
>>structure (although it is there as confirmed by some ported versions of 
>>gnu tar). So, the problem seems to be in the creation process on Windows...
> 
> 
> Sorry, I've been too busy lately and haven't been following this thread
> as closely as I should. One thing you should be aware of is trouble
> ticket 4437 at:
>   http://rt.cpan.org/NoAuth/Bugs.html?Dist=Archive-Tar&ShowAll=1
> As discussed in detail in this thread, tarballs created by Archive::Tar
> lose the directory information when unpacked/viewed with old versions of
> tarball viewers/extractors that do not properly implement the latest tar
> spec. IIRC, old versions of BSD tar and many versions of WinZip lose the
> directory information.
> 
> At the cost of making the A::T code somewhat ugly, I think an imperfect
> heuristic solution is possible, so that if all PATHs in the tarball were
> less than 100 characters in length, A::T could write the whole path at
> the front of the chunk and not use the 'prefix' field -- with a different
> code path, using the 'prefix' field, followed if any path in the tarball
> exceeds 100 characters in length.

AHA!  This sounds like a comment from an expert in A::T! or at least in 
the changes to the tar spec over time!  I appreciate the enlightenment 
it gives.

So I can at least get a glimmering of understanding about the issue... I 
can infer from what was said that:

* Old tar limited path names to 100 characters or less
* New systems permit more than that (even old system permit more than that)
* New tar implements new scheme for longer path names
* Old tar programs don't understand the new scheme, and show file names only
* For compatibility with the old programs and old specs, new programs 
could use the old scheme if the path names are less than 100 characters, 
which would work for many archives, actually.

Sounds like a good idea to me.

-- 
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick.  It's ridiculous.
-- Bill Gates

And here is why it is ridiculous:
  The division that includes Windows posted an operating profit of $2.26 
  billion on revenue of $2.81 billion.
  --from Reuters via 
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html

So that's profit of over 400% of investment... with a bit more 
investment in Windows technology, particularly in the area of 
reliability, the profit percentage might go down, but so might the bugs 
and security problems?  Seems like it would be a reasonable tradeoff. 
WalMart earnings are 3.4% of investment.