Stefan Monnier <[email protected]> writes: >>>>>> We'd also prefer a more common format, e.g. xz instead of lzip (which >>>>>> isn't supported by our standard unpacker), but this is a minor issue. >>>> This might also be difficult due to storage issues. >>> I find `lzip` to be much better behaved (which probably just means "more >>> like the other tools with which I'm familiar"), which is why I chose it. >>> I think it's also a bit closer philosophically to GNU. >> How so? Their command lines act the same.
Along these lines, note that the xz(1) manpage even says: In addition, decompression of the .lz format used by lzip is supported. I am not familiar with the Gentoo build system, even if they do not have lzip installed, they should be able to just use xz on our .lz files? > Interesting. I should have written "found" rather than "find". > That was many years ago when I was shopping for a gzip replacement, so > maybe I misremember the details (a quick web-search suggests, maybe > I was swayed also by some of the design/benchmark documents, that > suggested the author had designed the tool with a lot of care). > I've since used lzip for "everything" without looking back, really. Perhaps you encountered https://www.nongnu.org/lzip/xz_inadequate.html? > (Non)GNU ELPA has been using lzip for its old tarballs for the last > 5 years and this is the first time someone complains about it being too > obscure, so I'm not sure it's worth the trouble of changing. I think > I'd be more willing to consider a change to something newer/better than > lzip, rather than something whose only significant advantage is being > more popular. Considering the above, I am inclined to agree. But I think the question remains why we wouldn't want to provide a .lz'ed archive for the newest release of a package? > Stefan
