<p dir="ltr"><br>
Le 1 sept. 2014 14:21, "Guillem Jover" <<a href="mailto:guillem@debian.org">guillem@debian.org</a>> a écrit :<br>
><br>
> Hi!<br>
><br>
> I had noticed this a while ago while reading changelogs, but didn't<br>
> realize at the time this poses actual problems, besides being possibly<br>
> just a dubious practice.<br>
><br>
> There seems to be some packages overriding the default compression<br>
> level for xz to 9. This means dpkg-deb will require way more memory on<br>
> both compression and decompression usually for extremely little gain,<br>
> and might even fail on some systems with low memory (see #757740 for<br>
> an example). But the real issue is that (as mentioned on the xz man<br>
> page), using such high levels might actually make no sense at all<br>
> when being using with data that is smaller than the dictionary size.<br>
Could you fill a bug against lintian ?<br>
> From doing a quick search on <<a href="http://codesearch.debian.net/">http://codesearch.debian.net/</a>> for<br>
> “dpkg-deb.*-z9” and “dh_builddeb.*-z9”, but w/o looking in detail, it<br>
> seems that most packages are or have been maintained by Daniel Baumann<br>
> or the Fonts Team (both CCed). Was there an actual reason to use -z9,<br>
> beside maybe trying to get the “bestest” compression possible? :)<br>
><br>
> This could be checked from lintian by using something like:<br>
><br>
> $ ar x pkg.deb data.tar.xz<br>
> $ xz --list --verbose --verbose --robot data.tar.xz<br>
><br>
> and comparing the file sizes with the dictionary size used. I'll be<br>
> filing a bug report about this.<br>
><br>
> Thanks,<br>
> Guillem<br>
><br>
><br>
> --<br>
> To UNSUBSCRIBE, email to <a href="mailto:debian-devel-REQUEST@lists.debian.org">debian-devel-REQUEST@lists.debian.org</a><br>
> with a subject of "unsubscribe". Trouble? Contact <a href="mailto:listmaster@lists.debian.org">listmaster@lists.debian.org</a><br>
> Archive: <a href="https://lists.debian.org/20140901122030.GA25726@gaara.hadrons.org">https://lists.debian.org/20140901122030.GA25726@gaara.hadrons.org</a><br>
><br>
</p>