Re: The archive now supports xz compression
On 2011-08-11, Adam Borowski <kilobyte@angband.pl> wrote:
>> Think of both user systems and the Debian buildds which will waste more
>> time - an especially bad problem on slower architectures.
> The gain is especially meaningful for slower architectures, as they tend to
> have less disk space and slower network links (arm tends to be used in
> phones). No extra memory is needed -- decompression is not done in parallel
> with memory-hungry stages of dpkg's work. The decompression, merely 2.5
> times slower than with gzip, is a tiny fraction of what dpkg takes.
It takes a lot longer to compress on slower architectures (i.e. on the
buildds), though. You could've built a whole package in that time. (Resorting
to your style of argument.)
>> Please remember that packages in the base system[1] (and dependencies)
>> *must* currently use gzip as otherwise debootstrap will be unable to
>> install a system.
>>
>> 1: Meaning everything with Priority: required.
>
> I'm not as strongly opinionated here, but I guess decreasing the size of d-i
> images would be a huge win as well.
You cannot debootstrap it anymore. I can hardly call that a win. (So we'd
need to wait a few releases for that.)
> [1]. Three calls of system() could be avoided for little effort and two more
> for substantial effort -- and all of them could be turned into execve(), but
> otherwise, it's pretty much as fast as you can get. With package build time
> below a single disk seek, further optimizations are pointless. The point of
> "goodbye" was abuse of policy and buzzword compliancy, not speed.
It compiles the same script multiple times during build.
Kind regards
Philipp Kern
Reply to: