On Mon, Jan 13, 2025 at 12:34:14PM +1100, Simon Burge wrote: > 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).
Yes, I was thinking of unifying everything into just one method, but that would result in differences from the current situation indeed, hence my hesitation. In particular, there seem to be at least three things at play: * Release sets. These already have knobs for configuration. * Disk images. Compressed with gzip unconditionally. * Kernels. Compressed with gzip unconditionally. I do not know if there are good reasons for these differences, although I sense there aren't, and the reason sets support xz is because that's what made the most difference in final artifact sizes. We can take these one at a time and support differences among them if necessary. COMPRESS_RELEASE might not be a good idea at this point. But I'd still like to unify compression levels (to avoid the mess that are the -0 .. -9 flags throughout). -- Julio Merino
