[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Switching default dpkg-deb compressor to xz

On 8 May 2013 01:46, Raphael Hertzog <hertzog@debian.org> wrote:
> Hi,
> On Tue, 07 May 2013, Guillem Jover wrote:
>> As mentioned some months ago [0], I'm planning to switch dpkg-deb default
>> compressor from gzip to xz, as there seemed to be consensus that was
>> the way to go, and given the amount of already manually switched
>> packages, or packaging helpers. :/
> [...]
>> currently?). Otherwise I'll be doing the change with the dpkg 1.17.0
>> upload.
> I agree that we have such a consensus.
> There was a time where d-i was not ready, but nowadays udeb are compressed
> with xz and busybox's xz is used in that context.
> Please go ahead with this change (unless some other valid concerns are
> raised that is).

A while back I have raised a proposal on debian-devel, to include a
facility to opt-out of compressing packages. As a DEB_BUILD_OPTIONS
for example or via some other mechanism. Personally I have seen a
great build-time reduction, whilst doing test builds (or "slow" builds
on arm panda board / qemu), or whist doing a noopt & nostrip builds as
all of these builds are usually local and one may just one to have
the package simply sooner.

I have spotted an independent implementation in an ubuntu's
pkg-kde-tools (not sure if it's in debian one as well, at least it's
not in the experimental upload) that defaults to xz, yet honours
DEB_NO_XZ and DEB_NO_COMPRESSION environmental variables to disable
such compression.

Thinking more generically than last time around, would it be ok to
propose ability to set / override dpkg-deb compression options via
DEB_BUILD_OPTIONS? It would greatly simply rebuilding with no
compression / alternative algos and settings. In particular it will
ease to identify packages that do _not_ benefit from additional
compression and/or perform better under non-default compression
setting. I'm thinking of infamous openclipart, the one that has all
images pre-compressed and a couple dozen of other similar packages.

Should I open a bug and propose a change to debian-policy? Or do we
need to bikeshed more about this?

Last time around there was no significant arguments to not have such a facility.



Reply to: