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

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

On approximately 12/21/2003 5:31 PM, came the following characters from
the keyboard of Glenn Linderman:
> On approximately 12/21/2003 4:29 AM, came the following characters from
> the keyboard of Jos I. Boumans:
> 
>>
>> On Sun, 21 Dec 2003, [iso-8859-1] Andrew Savige wrote:
>>
>>> 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.
>>
>>
>> i'm very much opposed to this solution, since this still doesn't actually
>> /fix/ the problem; it's merely coding around a problem in /other/ tools,
>> and it will introduce a very fun /new/ 'bug' that distributions that keep
>> their longest path under 100 chars will do the right thing, and any
>> distribution with a path > 100 chars will now break... id much rather
>> document this shortcoming in other tools and add a dependency on a
>> /proper/ tar extractor, that follows the specs for the tar format... 
>> A::T,
>> gnu tar and quite a few others do... old bsd tars and some )"(#/"#)
>> windows tools dont.....
>>
>> just my $0.02
>>
>> -jos
> 
> 
> Interesting point of view.  That's sort of like outlawing all the old 
> cars that don't have some new safety feature, making it illegal to drive 
> them on the roads.
> 
> Sure seems to me that a high percentage of the tarballs in the world 
> have mostly paths less than 100 characters.
> 
> It is too bad that the old programs can look at the new tarball and see 
> a subset of the data, instead of reporting the real condition, at least 
> as a warning if not an error: "This tarball was produced using a version 
> of tar that implements a newer specification than this tar program.  To 
> see the tarball in its full detail, you should use a tar program that 
> implements specification GHI.  This tar program only implements 
> specification ABC."
> 
> That would explain the situation to the user.
> 
> On the other hand, for those tarballs that can be correctly created 
> according to the older specifications, without loss of functionality, 
> that is an extremely friendly feature even for a program that is capable 
> of creating tarballs using the new specifications, with new 
> functionality.  This sort of thing is called "backward compatibility", 
> and it encourages people to use the new program, since it interoperates 
> with the old, instead of encouraging them to throw the new program away, 
> sticking with the old tried and true and interoperable programs.
> 
> I have to admit that if I was under time pressure today to release my 
> new module (I still have a few weeks to go), that I would be extremely 
> tempted to discard both
> 
>    (1) Archive::Tar,
>    (2) Module::Build,
> 
> because
> 
>    (A) the  module that I built won't install properly using PPM (even 
> with A::T v1.07),
>    (B) I can't see the paths to the files using PowerArchiver 2001,
>    (C) I don't get warnings for each directory that is supposed to be in 
> the tarball, and

(C) is supposed to read "I _do_ get warnings..."  or maybe just "I get 
warnings..."

>    (D) I have other sample modules using MakeMaker and tar programs, 
> that do not suffer from (A), (B), and (C), so it is clearly a functional 
> path to take.
> 
> Since I have some lead time, I'll wait and see how this plays out over 
> the next few weeks.  People like backward compatibility, because it 
> makes things work.  And when things don't work, because of incremental 
> versionitis, it is nice if there is a built in method for reporting that 
> that is why, instead of simply providing reduced functionality without 
> warning.  Providing reduced functionality is OK, with the warning.  So 
> if an old tar program can extract the data, but not put it in the right 
> place, that is OK, if it tells me that it the tarball is a newer version 
> that it might not be able to fully decode.
> 
> The fact that there are bugs and deficiencies in old programs, however, 
> is no excuse for a new program not to be as backward compatible as it 
> can be.
> 
> Personally, I'd rather see archives stored as .zip files, which at least 
> were designed to do both archiving and compression in one step, rather 
> than play the two-step jig of .tar.gz.  But that's a whole 'nother 
> story, and an idea which probably won't get much momentum or attention, 
> because .tar.gz is there and works.  Well, given my above woes, sort of.
> 

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