Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
Antonio Diaz Diaz <antonio@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: