Re: The archive now supports xz compression
- To: debian-devel@lists.debian.org
- Subject: Re: The archive now supports xz compression
- From: Thorsten Glaser <tg@mirbsd.de>
- Date: Tue, 22 May 2012 12:15:10 +0000 (UTC)
- Message-id: <[🔎] Pine.BSM.4.64L.1205221205140.23033@herc.mirbsd.org>
- In-reply-to: <20110814220111.GM28976@codelibre.net>
- References: <877h6kasnv.fsf@deep-thought.43-1.org> <20110811183010.GA27546@angband.pl> <slrnj48coe.a7f.trash@kelgar.0x539.de> <20110814191902.GA3932@xanadu.blop.info> <20110814220111.GM28976@codelibre.net>
Roger Leigh dixit:
>Possibly a stupid question here but: Given that we are now autosigning
>builds, why can't the slower arches use gzip, and then after upload
>they could be recompressed with xz (and resigned) on a faster arch?
xz -2 is fast enough on m68k (IIRC, compresses not worse than bzip2 and
is not slower than gzip). I think you could justify even something like
xz --lzma=preset=3,dict=8M for speed freaks. However, see my mail in
<Pine.BSM.4.64L.1112192227580.856@herc.mirbsd.org> for a justification
for using xz -2 for most packages and xz -2e for packages with really
large data (that is not already precompressed, such as gzip’d manpages)
on not-fast architectures (with an allowance for -6[e] for debug, but
those wouldn’t be on the CDs anyway).
bye,
//mirabilos
--
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Reply to: