Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
On 06/13/2015 10:55 AM, Paul Wise wrote:
> On Sat, Jun 13, 2015 at 4:23 PM, Thomas Goirand wrote:
>> I've been using xz compression for a long time, but I see a big defect
>> which is today pushing me to turn it off for the .orig.tar file. The
>> issue is that depending on the version of xz-utils, it produces a
>> different output.
>> We use "git archive" within the PKG OpenStack team to generate this
>> tarball (which is more or less the same as pristine-tar, except we use
>> upstream tags rather than a pristine-tar branch). The fact that xz
>> produces a different result makes it not reproducible. As a
>> consequence, it is very hard for us to use this system across
>> distributions (ie: use that in both Debian and Ubuntu, or in Sid &
>> Jessie). We need consistency.
>> As a friend puts it:
>> "This is a fundamental problem/defect with xz. This (and a lot of
>> other such defects, e.g. non-robustness of xz archives that easily
>> lead to file corruption etc) are the reason that there is lzip (and
>> which is why gnu.org has, on a technical basis, decided that lzip is
>> official gzip-successor for gnu software releases when they come in
>> So it'd be super nice to have LZIP support in dpkg, and use that
>> instead of xz, archive wide.
>> Your thoughts everyone? Is there any reason why we wouldn't do that?
>> Thomas Goirand (zigo)
> It was already rejected by the dpkg maintainers twice.
Reading these bugs, am I right that the archive already supports lzip
for the orig.tar file? Because that's my issue: I don't really mind if
we use xz for the compression of the .deb files, but I need consistency
when generating the orig.tar.
Though, I had a try, and it doesn't look like dpkg-source -x supports
the .lz format unfortunately.
Now, regarding the fact that the maintainer closed the bugs, I see 2
issues the way he did it.
1/ First, he sites the fact that lzip isn't popular enough as the only
reason (did I miss another point of argumentation?). Well, it's
backed-up by the GNU project as the successor of gzip, and also, I
believe Debian is influential enough so that we may not have to care
about it. Also, a wise technical choice of this kind shouldn't be driven
by a popularity contest.
2/ Guillem wrote "that's at the maintainer's discretion" (ie: to close
the bug). Well, here, the whole of Debian is depending on this kind of
decision, so I don't agree that this decision is only at the discretion
of the maintainer.
Therefore, I'm tempted to raise this to the technical committee (putting
their list as Cc). Does anyone see a reason why I am mistaking here?
Thomas Goirand (zigo)