Thanks for writing that. Some minor points:
Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] selects the new pax format defined by POSIX
+1003.1-2001. It supports filenames with up to 65535 characters.
Hmm, where did that 65535 come from? I don't know of any limit of
65535
Paul == Paul Eggert [EMAIL PROTECTED] writes:
Paul Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] selects the new pax format defined by POSIX
+1003.1-2001. It supports filenames with up to 65535 characters.
Paul Hmm, where did that 65535 come from? I don't know of any
Alexandre Duret-Lutz [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] selects the new pax format defined by POSIX
+1003.1-2001. It supports filenames with up to 65535 characters.
POSIX 1003.1-2001 specification does not impose any limit on
lengths of files stored in PAX interchange format.
Alexandre Duret-Lutz [EMAIL PROTECTED] wrote:
Paul == Paul Eggert [EMAIL PROTECTED] writes:
Paul Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] selects the new pax format defined by POSIX
+1003.1-2001. It supports filenames with up to 65535 characters.
Paul Hmm,
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
[...]
Paul the existing code uses the -o option, which is [not portable]
[...]
Speaking about `o', I've just discovered that `missing' contains
some magic to strip that flag when tar fails, and retry.
It means that Roger's troubles should
Here is the patch I'm installing. Besides the doc update, and
the cpio -H $1 -i thing, I also changed the name of the cache
variable to include the _AM_PROG_TAR argument (so that
subpackages with different tar-xxx option do not share the same
cache variable).
As I've said, I'm also deliberately
Alexandre Duret-Lutz [EMAIL PROTECTED] wrote:
Sergey able to produce correct 'ustar' archives. Whatever
Sergey options you give to previous versions of GNU tar, the
Sergey produced archives will deviate from the standard.
Ouch! Is that a `will always deviate' or a `can deviate in some
Roger Leigh [EMAIL PROTECTED] wrote:
I didn't realise it supported generating tar files. For the cpio I
have (GNU cpio version 2.5):
ustar The POSIX.1 tar format. Also recognizes GNU tar archives,
which are similar but not identical.
How does this differ from tar
Paul Eggert [EMAIL PROTECTED] wrote:
Given all the hassles that will accompany any change, perhaps we
should give the maintainer a more gradual upgrade path.
For example, we could add an automake macro AM_TAR_FORMAT.
[...]
That's a nice idea. I'd vote for it.
I'd put cpio last on the
Paul == Paul Eggert [EMAIL PROTECTED] writes:
[...]
Paul Given all the hassles that will accompany any change, perhaps we
Paul should give the maintainer a more gradual upgrade path.
Paul For example, we could add an automake macro AM_TAR_FORMAT.
Paul AM_TAR_FORMAT([v7]) would use the
On Sun, 18 Apr 2004 23:18:05 +0200, Alexandre Duret-Lutz wrote:
[EMAIL PROTECTED] selects the new pax format defined by POSIX
+1003.1-2001. It supports filenames with up to 65535 characters.
+However this format is very young and should probably be avoided in
+all packages that do not target
Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
How about this scheme:
In the light of later discussion, how about this scheme instead?
Use the first of the following commands that works:
tar --format=ustar
tar
pax -x ustar
I wouldn't bother with POSIXLY_CORRECT=1 or tar -o, as
Roger Leigh [EMAIL PROTECTED] writes:
I'm using the patch I posted. If and when anyone complains, I'll
instruct them to build and install the latest GNU tar (or build it for
them). I require the functionality for long pathnames, and I don't
want to have to support broken tools. For my
Paul == Paul Eggert [EMAIL PROTECTED] writes:
Paul Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
How about this scheme:
Paul In the light of later discussion, how about this scheme instead?
Paul Use the first of the following commands that works:
Paul tar --format=ustar
Paul tar
Paul
Ralph Schleicher [EMAIL PROTECTED] writes:
Roger Leigh [EMAIL PROTECTED] writes:
I'm using the patch I posted. If and when anyone complains, I'll
instruct them to build and install the latest GNU tar (or build it for
them). I require the functionality for long pathnames, and I don't
want
Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
Paul tar --format=ustar
Paul tar
Paul pax -x ustar
This looks satisfactory when GNU tar 1.13.93 is installed, or
when GNU tar is not installed. However, on most GNU/Linux
setups, which have GNU tar 1.13.25 installed, my understanding
is
Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
1. The --format=posix options is a GNU Tar option, which means `make dist'
can no longer be run with other make implementations.
Presumably you meant tar implementations and not make
implementations? But this is already the case, as the
Hello,
Actually I was planning to address this issue a bit later, since I
do not have a solution for automake yet. Anyway:
Alexandre Duret-Lutz [EMAIL PROTECTED] wrote:
Roger + $(AMTAR) chf - $(distdir) --format=posix | GZIP=$(GZIP_ENV) gzip -c
$(distdir).tar.gz
[...]
Sorry for the
Paul == Paul Eggert [EMAIL PROTECTED] writes:
Paul Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
1. The --format=posix options is a GNU Tar option, which means `make dist'
can no longer be run with other make implementations.
Paul Presumably you meant tar implementations and not make
Sergey == Sergey Poznyakoff [EMAIL PROTECTED] writes:
[...]
Sergey Returning to the question which format should be chosen for
Sergey distribution tarballs: I would recommend the 'ustar' format.
Sergey It also has a limitation on the maximum length of stored pathnames,
Sergey but the
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
Paul == Paul Eggert [EMAIL PROTECTED] writes:
[...]
Forcing the ustar format might be a possibility (is it?), if
that can be done portably (that probably involves a configure
check).
Paul Yes, I think this is the best approach: that
Alexandre Duret-Lutz [EMAIL PROTECTED] wrote:
On second though, shouldn't we try to use pax first? tar is no
longer a POSIX requirement, right?
Right, but I'd say it's too early to relay on pax.
Also do we really need to try `-o'?
No, we do not.
Besides GNU tar, is there some tar
Alexandre Duret-Lutz [EMAIL PROTECTED] wrote:
I think it's the only place where I've read this. Has anybody
seen such implementation? I'm tempted to think we shouldn't
care.
Agreed.
Regards,
Sergey
On Fri, 16 Apr 2004, Alexandre Duret-Lutz wrote:
By the way, the pax manpage from the Heirloom Toolchest
(http://heirloom.berlios.de/man/pax.1.html) mentions that due
to implementation errors, file names longer than 99 characters
can not considered to be generally portable when taking about
Sergey == Sergey Poznyakoff [EMAIL PROTECTED] writes:
[...]
Otherwise use `POSIXLY_CORRECT=1 tar'. (I'm assuming that
POSIXLY_CORRECT=1 will coerce older tar versions into
producing ustar format. Am I wrong, or is there another
way?)
Sergey No, it will not. Previous versions of
Bob Friesenhahn [EMAIL PROTECTED] writes:
Is there a reason to allow file names longer than 99 characters in a
package? Clearly this is non-portable. Why not enforce a maximum
file name length of 99 characters in Automake?
I experience the breakage when using Doxygen to generate a reference
26 matches
Mail list logo
