On Sun, May 13, 2012 at 09:27:26AM +0200, Philipp Kern wrote: > On Sun, May 13, 2012 at 02:06:25AM +0200, Guillem Jover wrote: > > Also if udeb:s are going to be using xz then it makes even more sense to use > > it for everything. > > µdebs won't use the xz default, though. (The compression for them will be > handled in debhelper.) > > With the compression scheme I posted to -boot it doesn't need more memory than > gzip while still compressing better. I don't see any trouble in activating > xz for amd64/i386 immediately before the release, if the problem with the core > packages is solved. (I.e. debootstrap avoiding any ties to xz or avoiding the > compression of core packages.) Except that busybox has xz support, and is loaded from an udeb way before any regular debs are seen. Ie, there is no reason to stop "core packages" from using decent compression. There's no reason to keep it to amd64/i386 as well -- in fact, it's i386 which is most likely to use unassisted install with extremely low memory. I'm not aware of armel/mips boxes with 64MB ram that load d-i themselves. So if i386 can handle it, everything else can. The extra computation cost is paid on buildds, not the user's machine. Also, to solve the CD1 problem, dpkg-deb would have to switch _soon_, letting a big enough part of packages to be naturally rebuilt. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices.
Attachment:
signature.asc
Description: Digital signature