On Saturday 03 March 2012 16:12:47 James K. Lowden wrote: > On Sat, 3 Mar 2012 15:47:22 -0500 Mike Frysinger wrote: > > > As a project downstream from xz, if we must have yet another > > > compression format independent of gzip, why not let it live along > > > side the established one(s) until pretty much anything that links > > > to zlib or similar also supports xz? > > > > this makes no sense at all. by your logic, zlib/gzip should support > > every single compression that someone might use. > > No. By my logic, if you're going to replace gzip, you should augment > the library to permit backwards compatibility. no, that's crap logic. gzip/zlib are designed to handle the *gzip* compression scheme. FIN. xz is a diff compression scheme, hence diff util/library. to keep things simple, the command line interface for gzip/bzip2/xz use the same flags. attempting to reframe gzip as an arbitrary frontend for any compression scheme doesn't make sense. it never was that, and most likely never will be. if you want to be lazy and have one command that handles arbitrary compression/archiving, then use a project that does exactly that. there are a bunch out there. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
