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 list, with the lowest priority. I agree. > Traditional > UNIX cpio had serious bugs whenever two files had inode numbers that > were the same modulo 2**16. This problem persisted for many years (up > until I stopped using cpio -- perhaps it still has the bug for all I > know). GNU cpio cannot yet handle large files or archives (i.e., > larger than 2 GiB on typical x86 hosts). The CVS version is able to handle large files, however most distributions still ship cpio binaries compiled without large file support. Regards, Sergey
