12410 2017-12-07 21:47:14 +0000 cannot use pigz, pigz is not a drop in replacement for gzip 2018-02-20 20:14:20 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 2.5 x86 Multiple RESOLVED FIXED Medium+ normal 2.5 M2 1 juro.bystricky ross.burton meta.mr.watcher meta.watcher randy.macleod --- --- Don't know oldest_to_newest 78603 0 juro.bystricky 2017-12-07 21:47:14 +0000 The recipe for pigz builds pigz. Then it boldly installs the pigz binary under the name gzip (class-target installs fine, with update-alternatives). This is done based on the pigz claim that it is a drop-in replacement for gzip. There are several problems with this: A. pigz is NOT a drop in replacement for gzip: In particular: gzip -n pigz -n behave differently. You need to specify pigz -n -T to have the same affect as: gzip -n However, calling gzip with -T results in an error. So what do you do when you don't want any timestamsp in your compressed image? "gzip -n" does not work (because gzip is actually pigz) "gzip -n -T" would/could work, but this is wrong on many levels. B. Great confusion: If a recipe/class uses gzip, not clear which program is actually used: 1. Host gzip? 2. gzip-native? 3. pigz? We need to know this in order to use correct command line arguments. C. An obvious fix would be to call "pigz" if we want "pigz" or "gzip" if we want "gzip". This does not work as there is no "pigz" binary. At the very least there should be pigz binary (maybe with a symlink as gzip..) So pretending pigz is the same as gzip is not just confusing but also (in some cases) wrong. 78721 1 juro.bystricky 2017-12-18 16:11:20 +0000 I tested Fedora26: $ which gzip /usr/bin/gzip $ /usr/bin/gzip --version gzip 1.8 $ which pigz /usr/bin/pigz $ /usr/bin/pigz --version pigz 2.3.4 So on Fedora26 gzip/pigz are installed as two separate programs. 79362 2 ross.burton 2018-02-06 12:00:45 +0000 Patch on the list. 79516 3 ross.burton 2018-02-20 20:14:20 +0000 Fixed in oe-core 1624b7bfea7ac31c344a6cfcc7865a038e943814.