Submitted patch to OE-Core for review.
http://lists.openembedded.org/pipermail/openembedded-core/2016-March/118992.html

Can you explain how you are creating the externally produced rpms and what your expected workflow is?

Just  to be sure, can you confirm that these files are in fact rpm5 format?

Mark Hatle please follow-up here with advice or pointers to workflow docs since producing rpm5 files externally may need special attention or SDK support.

This is already implemented, this is not a bug.

If it does not work, add a failure condition to this defect and assign it to me.

Use the PACKAGECONFIG options in your project's distribution or local.conf file to enable the optional arguments for RPM.  Items you may be interested in:

Default is:  PACKAGECONFIG ??= "db bzip2 zlib popt openssl libelf python"

You might be interested in the following.

PACKAGECONFIG[xz] = "--with-xz,--without-xz,xz,"
PACKAGECONFIG[xar] = "--with-xar,--without-xar,xar,"


Note enabling xz enables both xz and lzma options, as they are really the same thing.

The patch was to simply enable xz by default.  Personally I'm not convinced that's a sensible thing to do as it pulls in more libraries for a package format that we don't use.

(*if* there was a series to switch our packages to use xz then that would be different)

In order to use/install (source) RPM packages produced in the xz format, you can use rpm2cpio.  Then when you build the package from source, it will use whatever format RPM is configured for.

With that said, I did comment on the patch on the oe list, but I'm going to repeat part of it below:

> If you can profile what adding the xz option does to a filesystem, I may change
> my mind.  The profiling needs to include the size change to RPM program itself,
> the produced filesystem (as it now has additional dependencies), and the package
> feeds size.
>
> My guess, is:  RPM binary will increase in size marginally..  including XZ and
> associated items could be potentially 'large'.. and the size of the package
> feeds will be reduced, but I don't have a good feeling as to how much.

Ross, in order to switch to using XZ by default, the 'macros' file for the rpmbuild process will need to be updated as well:

#       Compression type and level for source/binary package payloads.
#               "w9.gzdio"      gzip level 9 (default).
#               "w9.bzdio"      bzip2 level 9.
#               "w6.lzdio"      lzma level 6 (legacy, stable).
#               "w6.xzdio"      xz level 6 (obsoletes lzma, unstable).
#
#%_source_payload       w9.gzdio
#%_binary_payload       w9.gzdio

Ignore the stable or not comments above, I don't believe they are relevant anymore.  But the key is you want to swap out gzdio with xzdio or lzdio.  (It should remain as w9.)

This goes to my previous comment about profiling -- if we consider a switch here, changing that is the only way the produced package feed will shrink in size.. (I'd forgotten about that originally.)

After reviewing the feedback, I will not pursue for upstream the changes to OE-Core. I will implement the changes on my own layer. Thanks!