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

Re: Please test gzip -9n - related to dpkg with multiarch support

Guillem Jover <guillem@debian.org> writes:

> On Wed, 2012-02-08 at 22:01:23 +0100, Jakub Wilk wrote:
>> In practice, the only compressor we need to care is gzip, which is
>> not actively maintained upstream[0]. Chances that a new version of
>> it will break large number of packages are minute.
> That assumes that we will never want to switch to a better/faster
> compressor for any gzip compressed file. Or that there's no existing
> files compressed with anything other than gzip.
>> But anyway, I believe that in the long run we should simply
>> deprecate compressing stuff in /usr/share/doc/.
> So the main reason people are arguing for shared files boils down to
> used size, either in installed files, or Packages files, etc, yet you
> want to fix the compression issue by not compressing them and using
> even more space?
> While this could benefit the multiarch installations (for which they
> can easily use --path-exclude), it would use lots more space on single
> arch installations.
> Also splitting files into new arch:all packages should usually reduce
> archive size usage for example.
> regards,
> guillem

There are 2 cases to consider here:

1) Lots of data in /usr/share/doc/

Please do split them into an arch:all package.

2) Tiny amount of data in /usr/share/doc/

Policy requires that we have a Changelog there and those are usualy
large enough to benefit from compression but not large enough to warant
their own -common package. Adding one or two other small files as docs
usualy doesn't pass the thresshold for splitting them into -common too.

Now those are our problem cases where we need identical compression.
But if it is such a tiny amount then keeping it uncompressed should be
reasonably fine. Systems where those few extra kib make a difference
probably want to --path-exclude /usr/share/doc.

There could also be a new option "--path-compress <compresor> <path>"
that would compress any file below that path with the given compressor.

So my suggestion would be twofold:

1) encourage splitting stuff into -common packages
2) leave files uncompressed in MA:same packages


Reply to: