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

Bug#909696: lintian: debian-rules-should-not-use-custom-compression-settings overzealously also reports -Zgzip



On Thu, Sep 27, 2018 at 01:02:11AM +0200, Axel Beckert wrote:
> Package: lintian
> Version: 2.5.106
> 
> Hi,

Hi Axel,

first of all apologies for the late reply (and thanks to Chris for the ping).

> according to the bugreport https://bugs.debian.org/829100 this tag was
> primarily meant to catch too high xz compression settings. Also the
> lintian long description seems to be targetted towards that case.

Agreed that the description for this tag as well as for 
debian-source-options-has-custom-compression-settings
is no lomger correct.

What about adding the following pararaph after the
"Whilst higher levels" paragraph:

Other compression level or algorithm changes are less harmful, but 
unless there is an exceptional reason why different settings are 
important for a package the defaults should be used. This also
makes future archive-wide changes of the defaults easier.

> But this tag is also emitted on the rather conservative "-Zgzip" option
> which is not that uncommon if you want to keep a package being able to
> be installed on Debian Wheezy ELTS or Ubuntu 12.04 ESM (both are still
> supported to some degree and have dpkg 1.16.x. And at least dpkg in
> Wheezy has no xz support).

It is not supported to install packages that were built on buster on 
distributions older than stretch, the recommended way is to rebuild
the package for the target release - even the hello binary package
in stretch has a libc6 dependency that cannot be fulfilled in wheezy.

Also note that only 7 of the 234 emitted tags are for -Zgzip. I can see 
that the one in debootstrap was intentional, and the "-Zgzip -z1"in the 
3 ufoai-* packages might have been due the contents already compressed.
But these are rare exceptions, and noone is objecting to a lintian
override in such cases. The other 3 -Zgzip usages look incorrect at 
first sight.

For debian-source-options-has-custom-compression-settings 24 out of 503 
warnings are for gzip. Except for debootstrap (again) there is none that 
looks at first sight justified.

> So IMHO this tag should not be emitted with legacy compression formats
> like gzip or bzip2

The bzip2 cases I have seen so far were manual settings to a better 
compression than the then-default gzip long ago, that do now give
worse compression than the current default.

In general I do not see any usecase anywhere left for bzip2,
gzip is more portable and xz compresses better.

> (at least not with those which were default in the
> past), just with too high (but not too low) xz compression settings or
> more exotic (never having been default, like IIRC lzma) compression
> formats.

AFAIK lzma is not permitted in the archive.

> I though see that explicitly using legacy compression formats
> (especially bzip2 comes to my mind) may no more be supported in dpkg in
> some future release, so it might be good to warn about that, too. But
> that's by far less severe that too heavy xz compression settings.
> 
> So maybe this should be split up into two tags:
> 
> * too exotic/strong settings (warning level; current long desc.)
> * conservative, maybe not future-proof settings which once were default
>   (pedantic level; new long desc.)

In my experience ~ 99% of all packages that fiddle with compression 
options shouldn't have been doing that ever, and that this should be a 
warning level lintian message so that it gets fixed and won't interfere 
if the defaults get changed again in the future.

Like hundreds of packages doing nothing other than the default with
-Zxz right now is clearly not severe, but with a lintian warning it 
becomes visible for the maintainer that this should be removed.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


Reply to: