Antonio Diaz Diaz <anto...@gnu.org> writes: > I am not discussing a concrete use case. I understand that the defects > in xz are usually not a big problem for Debian packages that can be > easily downloaded again in case of corruption.
> What I find wrong here is that by using xz in its packaging system, > Debian is sending the message that xz is a good format to use, which is > not true for many other use cases. > Inversely, by not accepting .lz source tarballs Debian is sending the > message that lzip is not a good format to use, While it's possible that people may decide to read such messages into our decisions, that's not really something we have control over, and I don't believe we should alter our decisions on that basis. We should choose the best compression format (or formats) for our particular use case, not choose a compression format on the basis of what sort of message other people may read into that decision for other use cases. > and is wasting time, storage and bandwidth recompressing lzip sources: This is probably the strongest argument that I've seen presented on this thread for supporting lzip in *source packages*: not needing to recompress upstream releases that use lzip exclusively (or use only lzip plus other compression formats that we don't want to support). However, it's not at all clear to me that there are enough of those packages to make this use case particularly compelling. There are two different things we can tune in the Debian packaging system here: the compression formats supported for upstream tarballs in source packages, and the compression format used for binary debs and for the Debian-specific portions of source packages. Historically, we've used a broader range of compression formats for the former than for the latter. But supporting a compression format for upstream source should be driven by how much packaging effort it saves, since compression ratios for the source packages isn't all that exciting (they're not downloaded nearly as often, and they're often smaller anyway). For binary debs, we went through a long evaluation process that showed some pretty clear benefits for xz over gzip, and then went through a long transition process. Changing this is hard and time-consuming, and therefore requires a lot of evidence that it's worth the change. When we went from gzip to xz, we saw substantial improvements in deb size that mattered for some use cases. I think to switch to lz compression would require gathering a similar compelling case that lz is sufficiently better than xz right now *for our use case* that it's worth changing. (I believe the whole decision-making process for xz required a year or two.) So, there are two things in Debian that could switch to lzip, and two separate paths forward for making an argument for those two things. I don't think this thread is really helping with either path, and would recommend that you focus gathering of evidence (backed by real numbers and reproducible statistics, the way the xz discussion previously was) for either: 1. Support lzip for upstream tarballs based on the number of upstreams that are using lzip as their preferred compression format and the gains in ease of packaging of that software. 2. Support lzip for binary packages based on some comprehensive advantages specifically for our binary package format over existing compression methods. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wpxlnzsq....@hope.eyrie.org