> (in which Tiger's newly metadata-enabled command line apps, such as
> tar, silently add files like ._Makefile.PL to get around apple's
> complete failure to put together a coherent strategy for managing
> file information, which MakeMaker sensibly tries to run, and fails.
> See eg http://caseywest.com/journal/archives/004393.html)
Death to Apple!
> I'm reluctant to install Gnu tar. I imagine that Apple is about to do
> something that relies on tar unpacking metadata. Is that silly of me?
If you leave the system tar(1) alone, and install GNU tar elsewhere (eg
in /sw if you use fink) *and* if you don't edit any system config stuff
like $PATHs, just edit your own $PATH in your .bash_whatever files to
put GNU tar first in your $PATH, then you *should* be OK. Treat it as
you would perl, where you would install your own perl build and leave
Apple's own perl well alone.

Signature
David Cantrell | Hero of the Information Age
I remember when computers were frustrating because they did
exactly what you told them to. That seems kinda quaint now.
-- JD Baldwin, in the Monastery
William Ross - 07 Oct 2005 19:12 GMT
>> (in which Tiger's newly metadata-enabled command line apps, such as
>> tar, silently add files like ._Makefile.PL to get around apple's
[quoted text clipped - 15 lines]
> you would perl, where you would install your own perl build and leave
> Apple's own perl well alone.
Thank you. Very neat and simple and I should have thought of that.
will
Joel Rees - 08 Oct 2005 01:38 GMT
(Sorry about the double, David. Either AppleMail needs a reply-to-list
button or I need to wake up before I post.)
>> (in which Tiger's newly metadata-enabled command line apps, such as
>> tar, silently add files like ._Makefile.PL to get around apple's
[quoted text clipped - 3 lines]
>
> Death to Apple!
heh.
>> I'm reluctant to install Gnu tar. I imagine that Apple is about to do
>> something that relies on tar unpacking metadata. Is that silly of me?
Yes and no. It's a potential problem until the industry establishes
some standard to deal with metadata when flattening files for
transmission over (metadata ignoring) media. And that means we need to
understand the problem.
Hate to ask the obvious, but did you try man tar? (If I were at work I
could check to see if it would be worthwhile, but I have no 10.4 boxes
at home.)
I scrolled past some of the SPAM and noticed a message that seems to
indicate to me that the problem might not exist on a case sensitive
volume.
> If you leave the system tar(1) alone, and install GNU tar elsewhere (eg
> in /sw if you use fink) *and* if you don't edit any system config stuff
> like $PATHs, just edit your own $PATH in your .bash_whatever files to
> put GNU tar first in your $PATH, then you *should* be OK. Treat it as
> you would perl, where you would install your own perl build and leave
> Apple's own perl well alone.
This is the correct approach if you must have a standard tar, as
opposed to what the blog you linked (minus the trailing paren) suggests.
William Ross - 10 Oct 2005 01:13 GMT
>> If you leave the system tar(1) alone, and install GNU tar
>> elsewhere (eg
[quoted text clipped - 9 lines]
> opposed to what the blog you linked (minus the trailing paren)
> suggests.
As it turns out, apple actually supply gnu tar as well as their own
version. There's a /usr/bin/gnutar, anyway, but oddly it too
leaves ._files in the archive.
The version of tar I already had (blush) in /sw/bin/tar works as
expected, though. Which means the answer to building a compatible
distribution tarball under tiger is just to add this to the
WriteMakefile call:
dist => {
TAR => "/sw/bin/tar",
}
It works for me, anyway.
best,
will