Bug 9246

Summary: rpm: enable xz/lzma compression
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Rebecca Chang <rebecca.swee.fun.chang>
Component: devtools / tool chainAssignee: Rebecca Chang <rebecca.swee.fun.chang>
Status: RESOLVED INVALID QA Contact:
Severity: normal    
Priority: Medium CC: anuj.mittal, mark.hatle, mei.yeen.ng, meta.mr.watcher, meta.watcher, randy.macleod, rebecca.swee.fun.chang, richard.purdie, ross.burton, sgw
Version: 2.0   
Target Milestone: 2.0.2   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)

Description Rebecca Chang 2016-03-14 07:03:26 UTC
We need rpm to support xz and lzma compression to unpack rpm files.
Comment 1 Rebecca Chang 2016-03-14 07:18:07 UTC
Submitted patch to OE-Core for review.
http://lists.openembedded.org/pipermail/openembedded-core/2016-March/118992.html
Comment 2 Randy MacLeod 2016-03-17 15:35:36 UTC
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.
Comment 3 Mark Hatle 2016-03-17 15:48:10 UTC
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.
Comment 4 Ross Burton 2016-03-17 15:59:33 UTC
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)
Comment 5 Mark Hatle 2016-03-17 16:01:17 UTC
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.
Comment 6 Mark Hatle 2016-03-17 16:03:20 UTC
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.)
Comment 7 Rebecca Chang 2016-03-22 01:46:16 UTC
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!