Created attachment 545141 [details] Broken repomd.xml file (bz2 comps.xml referenced in 'group_gz') Description of problem: When hosting yum repos on Fedora 16. Createrepo creates repositories which are incompatible with the version of yum in CentOS 6.0. Version-Release number of selected component (if applicable): Centos 6.0 client yum: -bash-4.1# yum --version 3.2.27 Installed: rpm-4.8.0-12.el6.i686 at 2011-12-10 23:54 Built : CentOS BuildSystem <http://bugs.centos.org> at 2010-11-12 00:21 Committed: Panu Matilainen <pmatilai> at 2010-07-09 Installed: yum-3.2.27-14.el6.centos.noarch at 2011-12-10 23:54 Built : CentOS BuildSystem <http://bugs.centos.org> at 2011-04-29 12:19 Committed: Karanbir Singh <kbsingh> at 2011-07-22 Installed: yum-plugin-fastestmirror-1.1.26-11.el6.noarch at 2011-12-10 23:54 Built : CentOS BuildSystem <http://bugs.centos.org> at 2010-11-12 00:37 Committed: James Antill <james.antill> at 2010-07-14 Fedora 16 createrepo: createrepo 0.9.9 Steps to Reproduce: 1)Create a yum repository by copying the contents of the CentOS-6.0 install media to a httpd accessible location. rsync /mnt/iso /var/www/html/cent-6.0 cd /var/www/html/cent-6.0 createrepo -s sha -c cache --compress-type=bz2 -g repodata/<sha hash>-comps.xml /var/www/html/cent-6.0 1. Attempt to do 'yum grouplist' from centos 6.0 box Actual results: -bash-4.1# yum grouplist Loaded plugins: fastestmirror Setting up Group Process Determining fastest mirrors core-0 | 3.1 kB 00:00 core-0/primary_db | 2.8 MB 00:00 Failed to add groups file for repository: core-0 - comps file is empty/damaged Done The comps.xml file is compressed with bzip2 -bash-4.1# ls -l repodata total 15772 -rw-r--r--. 1 root root 4029486 Dec 10 22:53 142aec800672728599718f165093ae96bea93c09-filelists.xml.gz -rw-r--r--. 1 root root 1197476 Dec 10 22:53 1a6c40d940c195cf696ef5940a3d788c5f3c8a21-comps.xml -rw-r--r--. 1 root root 2959920 Dec 10 22:53 2e93fd66578d5daecc81db6a1273b0eafae95d61-primary.sqlite.bz2 -rw-r--r--. 1 root root 908561 Dec 10 22:53 45803196b0501e8572c02ed83c9cb002c7eb0009-other.xml.gz -rw-r--r--. 1 root root 1300949 Dec 10 22:53 514385799c5720739bb95caeaa9112daa726e023-other.sqlite.bz2 -rw-r--r--. 1 root root 4124029 Dec 10 22:53 676c7266f246f637165a6422dd6115b7019d3d19-filelists.sqlite.bz2 -rw-r--r--. 1 root root 1486499 Dec 10 22:53 f1895f1e8170d410f6b63901b1c994e9adc33836-primary.xml.gz -rw-r--r--. 1 root root 127338 Dec 10 22:53 fa2d0a3cad2661d589b7d8dae57cebaea22e1d83-comps.xml.bz2 -rw-r--r--. 1 root root 3131 Dec 10 22:53 repomd.xml Expected results: Apparently the centos 6 version of yum is expecting the comps.xml file to be compressed with gzip. When I manually compress the comps.xml file using gzip and modify repomd.xml to point to the gzip version of comps.xml in the 'group_gz' section. the 'yum grouplist' command works. This is how the contents of a working repodata folder look: -bash-4.1# ls -l repodata-working/ total 15984 -rw-r--r--. 1 root root 4029486 Dec 10 22:08 142aec800672728599718f165093ae96bea93c09-filelists.xml.gz -rw-r--r--. 1 root root 1197476 Dec 10 22:09 1a6c40d940c195cf696ef5940a3d788c5f3c8a21-comps.xml -rw-r--r--. 1 root root 2959920 Dec 10 22:09 2e93fd66578d5daecc81db6a1273b0eafae95d61-primary.sqlite.bz2 -rw-r--r--. 1 root root 214325 Dec 10 22:10 30c29dd535b8a73f6801eb4b2b62d5f3754cde81-comps.xml.gz -rw-r--r--. 1 root root 908561 Dec 10 22:08 45803196b0501e8572c02ed83c9cb002c7eb0009-other.xml.gz -rw-r--r--. 1 root root 1300949 Dec 10 22:08 514385799c5720739bb95caeaa9112daa726e023-other.sqlite.bz2 -rw-r--r--. 1 root root 4124029 Dec 10 22:09 676c7266f246f637165a6422dd6115b7019d3d19-filelists.sqlite.bz2 -rw-r--r--. 1 root root 1486499 Dec 10 22:08 f1895f1e8170d410f6b63901b1c994e9adc33836-primary.xml.gz -rw-r--r--. 1 root root 127338 Dec 10 22:09 fa2d0a3cad2661d589b7d8dae57cebaea22e1d83-comps.xml.bz2 -rw-r--r--. 1 root root 3128 Dec 10 22:17 repomd.xml Attached are both of the repomd.xml files
Created attachment 545142 [details] Manually repaired repomd.xml file (comps.xml.gz properly referenced in 'group_gz')
what version of yum are you using in centos? I think the most recent version of yum released in rhel can handle this w/o a problem.
from the original comment above :) -bash-4.1# yum --version 3.2.27 Installed: rpm-4.8.0-12.el6.i686 at 2011-12-10 23:54 Built : CentOS BuildSystem <http://bugs.centos.org> at 2010-11-12 00:21 Committed: Panu Matilainen <pmatilai> at 2010-07-09 Installed: yum-3.2.27-14.el6.centos.noarch at 2011-12-10 23:54 Built : CentOS BuildSystem <http://bugs.centos.org> at 2011-04-29 12:19 Committed: Karanbir Singh <kbsingh> at 2011-07-22 Installed: yum-plugin-fastestmirror-1.1.26-11.el6.noarch at 2011-12-10 23:54 Built : CentOS BuildSystem <http://bugs.centos.org> at 2010-11-12 00:37 Committed: James Antill <james.antill> at 2010-07-14 I upgraded yum and yum-metadata-parser on centos (to the centos 6.1 version --don't recall exact ver number) and the "broken" repodata directory works as expected. You are correct. The latest version of yum does work. This raises a question of if the bug in createrepo needs to be fixed. My vote is yes as to avoid problems when doing installations of centos6.0 (the default set of packages does not get installed with the bug present). And some places don't do point release updates until much later.
I don't think it's reasonable to expect fedora releases to go out of their way to ensure that createrepo works with centos versions of yum. Moreover if you don't use --compress-type=bz2 then centos 6.0 should work fine. I'm inclined to close this notabug.
(In reply to comment #4) > I don't think it's reasonable to expect fedora releases to go out of their way > to ensure that createrepo works with centos versions of yum. I get that. And agree. > > Moreover if you don't use --compress-type=bz2 then centos 6.0 should work fine. > There is a related(maybe) issue which stops yum from working alltogether when you omit the --compress-type=bz2 flag when interacting with a f16 built yum repo. This I wrote off as a change in the metadata when I found that adding the flag caused yum to *almost* work. > I'm inclined to close this notabug. Feel free. This is mostly a corner case as those who are super worried about stability are not going to be hosting their yum repos on F16. And on the other side, the people who will be using the most recent release of centos/rhel will already have a working version of yum. I'll make sure I blog about my findings so the next guy who runs into this problem won't have to spend a week trying to debug it. :) -- Derek
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.