Hi Julio, Julio Merino wrote:
> I'm currently working on a NetBSD-based embedded disk image and, while > working on this project, the compression of various artifacts during the > build gets in the way. Compressing the sets and kernels is very visible > the choke point of the build even on a fast machine, and is specially so > when xz is in use. But the thing is: compression is completely useless > (for me) during the development cycle. If you don't want the compressed sets in your development cycle can you just use "./build.sh ... distribution" to skip generating the sets? > I started with a simple idea to preserve current behavior yet allow me > to disable sets compression: > > 1. Add a new COMPRESS_SETS tunable that takes no/gzip/xz as values. > The "no" value is what allows a user to disable compression. > 2. Deduce the default value of COMPRESS_SETS with the same logic we have > today based on USE_XZ_SETS/USE_PIGZGZIP. COMPRESS_SETS=no would never > be set by default today. > 3. Retire USE_XZ_SETS. A better control knob for sets wouldn't be unwelcome (IMO) :). > The general idea would be to replace COMPRESS_SETS (not yet even committed) > with a more generic COMPRESS_RELEASE (or similar name) and use that value > wherever the release build wants to produce compressed artifacts. Then, > unify the many -0, -9, -n... flags that appear throughout the tree for gzip > and xz in one single place so that, when compression is indeed enabled, we > apply it consistently. Note that we sometimes use an explicit compression method elsewhere in the build (eg compressing kernels) that might differ from the compression method for sets. The way I read your proposal you seem to be suggesting "everything in the build that needs to be compressed will be compressed with the thing expressed by COMPRESS_RELEASE"; I'm pointing out that this might break some things. Now, whether or not the things that are compressed differently are for a valid reason is a different question! I can think, for example, that an image that is designed to be dd'd to the start of a memory stick might explicitly be compressed with gzip because it might be easier to decompress a .gz file on a Windows box (I don't know this to be the case, just using as a possible reason for preferring a different compressor). Cheers, Simon.
