When I try to use gzip-native (as opposed to host gzip), I set in my local.conf: do_rootfs[depends] += "gzip-replacement-native:do_populate_sysroot" EXTRANATIVEPATH += "gzip-native" and then: $ bitbake core-image-minimal complains: ERROR: Multiple .bb files are due to be built which each provide gzip-native:######## | ETA: 0:00:03 virtual:native:/data/master/poky/meta/recipes-extended/pigz/pigz_2.3.4.bb virtual:native:/data/master/poky/meta/recipes-extended/gzip/gzip_1.8.bb A list of tasks depending on these providers is shown and may help explain where the dependency comes from. virtual:native:/data/master/poky/meta/recipes-extended/pigz/pigz_2.3.4.bb has unique dependees: virtual:native:/data/master/poky/meta/recipes-core/expat/expat_2.2.3.bb:do_unpack /data/master/poky/meta/recipes-core/expat/expat_2.2.3.bb:do_prepare_recipe_sysroot virtual:native:/data/master/poky/meta/recipes-core/expat/expat_2.2.3.bb:do_prepare_recipe_sysroot /data/master/poky/meta/recipes-core/expat/expat_2.2.3.bb:do_unpack virtual:native:/data/master/poky/meta/recipes-extended/gzip/gzip_1.8.bb has unique dependees: It could be that one recipe provides something the other doesn't and should. The following provider and runtime provider differences may be helpful. virtual:native:/data/master/poky/meta/recipes-extended/pigz/pigz_2.3.4.bb has unique provides: pigz-native virtual:native:/data/master/poky/meta/recipes-extended/pigz/pigz_2.3.4.bb has unique rprovides: pigz-native virtual:native:/data/master/poky/meta/recipes-extended/gzip/gzip_1.8.bb has unique provides: gzip-replacement-native virtual:native:/data/master/poky/meta/recipes-extended/gzip/gzip_1.8.bb has unique rprovides: gzip-native I definitely cannot use the host gzip, so how do I proceed?
I should mentioned that I also tried all kinds of PREFERRED_PROVIDER settings, such as: PREFERRED_PROVIDER_gzip-native = "gzip-native" PREFERRED_PROVIDER_gzip-native = "gzip-replacement-native" PREFERRED_PROVIDER_virtual/gzip-native="gzip-native" until I ran out of ideas.
I should mention that I need to differentiate between pigz and gzip, as (contrary what pigz claims) pigz ** does not ** support identical command line options as gzip. In particular: gzip -n pigz -n behave differently. I think you need to specify pigz -n -T to emulate gzip -n However, I don't think gzip supports -T. So pretending pigz is the same as gzip is not just confusing but also (in some cases) wrong.
I will file a separate bug reflecting the fact taht pigz is not a drop in replacement for gzip.
The fix for 12410 handles this too.
Fixed in oe-core 1624b7bfea7ac31c344a6cfcc7865a038e943814 by ensuring that pigz isn't a gzip replacement.