Re: [PATCH v2] use xz and gzip on host (outside chroot)

[Baurzhan Ismagulov <ibr@radix50.net>]

On Mon, Aug 08, 2022 at 05:30:49PM +0200, Henning Schild wrote:
> > diff --git a/meta/classes/imagetypes.bbclass b/meta/classes/imagetypes.bbclass index 1e8e223d..319e9dc8 100644
> > --- a/meta/classes/imagetypes.bbclass
> > +++ b/meta/classes/imagetypes.bbclass
> > @@ -95,13 +95,13 @@ IMAGE_CMD_ubi[depends] =
> > "${PN}:do_transform_template" # image conversions
> >  IMAGE_CONVERSIONS = "gz xz"
> >  
> > -CONVERSION_CMD_gz = "${SUDO_CHROOT} sh -c 'gzip -f -9 -n -c
> > --rsyncable ${IMAGE_FILE_CHROOT} > ${IMAGE_FILE_CHROOT}.gz'"
> > -CONVERSION_DEPS_gz = "gzip" +CONVERSION_CMD_gz ?= "gzip -f -9 -n -c
> > --rsyncable ${IMAGE_FILE_HOST} > ${IMAGE_FILE_HOST}.gz"
> > +CONVERSION_DEPS_gz ?= "" 
> 
> No. Please only add the ? so you can take the shortcut in your layer,
> without changing the conservative and slow isar defaults.

I agree in principle that such cases occur from time to time. I've seen mke2fs
producing filesystems that were unreadable by older kernels due to some flags
and compression tool option differences (the latter not applying in this case).

In practice, I think such cases are quite rare; for this potential
compatibility, we'd pay performance penalty every day. So, I'd like to benefit
from this finding, in Isar, by default. If we can always switch back to the
slower variant, that sounds as Good Enough for me.

An alternative could be to compress from the host chroot regardless of the
cross-compilation setting. While at it, we could also evaluate pigz (it would
be interesting to see some benchmarks on the list) and recheck the reasons why
cross-compilation was disabled for the imager -- maybe it's solvable this time.

With kind regards,
Baurzhan