On 2011-08-11, Adam Borowski <kilob...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnj48coe.a7f.tr...@kelgar.0x539.de