Bug 1125437 - createrepo --compress-type=xz results in primary.xml.gz and friends
Summary: createrepo --compress-type=xz results in primary.xml.gz and friends
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: createrepo
Version: 7.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Michal Domonkos
QA Contact: Eva Mrakova
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-31 20:30 UTC by Pat Riehecky
Modified: 2017-08-01 22:16 UTC (History)
7 users (show)

Fixed In Version: createrepo-0.9.9-28.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-08-01 22:16:03 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2024 normal SHIPPED_LIVE createrepo bug fix update 2017-08-01 19:32:17 UTC

Description Pat Riehecky 2014-07-31 20:30:01 UTC
Description of problem: When running createrepo --compress-type=xz not all resulting compressed metadata is compressed with xz.

Version-Release number of selected component (if applicable):createrepo-0.9.9-23.el7

How reproducible:100%

Steps to Reproduce:
1.createrepo --compress-type=xz .
2.ls repodata/*.gz
3.files are present

Actual results:
some files are created with gzip compression

Expected results:
xz compression used for all files

Additional info:
__init__.py from createrepo has a 'FIXME' relating to y-m-p in the relevant code

Comment 3 Karel Srot 2015-05-29 11:38:36 UTC
While I was testing bug 874682 I did a note to the test that preserving gz format for primary metadata with --compress-type=xz was intentional but I cannot find the reason for that... 

James or Valentina, 
do you know why? Maybe we thought it could be risky for RHEL-6 since pyliblzma is not present in RHEL6.

Comment 4 Pat Riehecky 2015-05-29 13:52:59 UTC

Closest I've got for reasoning, but this doesn't truly clear your needinfo

Comment 5 James Antill 2015-06-16 13:34:29 UTC
(In reply to Karel Srot from comment #3)
> do you know why? Maybe we thought it could be risky for RHEL-6 since
> pyliblzma is not present in RHEL6.

It was simpler than that, at the time we passed the downloaded .xml files directly to yum-metadata-parser. And that used gzopen() if the file ended in .gz or open() otherwise.

Between el6 => el7 we changed yum so it decompresses the .xml files itself, and passes the result to yum-metadata-parser, avoiding this problem. So we could fix this in createrepo now.

Comment 6 Michal Domonkos 2016-11-22 12:31:27 UTC
Acking (fix hinted in comment 5).

Comment 11 errata-xmlrpc 2017-08-01 22:16:03 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.