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
or
2) leave files uncompressed in MA:same packages
MfG
Goswin
Reply to: