Description of problem: createrepo creates arch="i386" for src.rpm files. At least the following (taken from filelists.xml.gz) created by createrepo looks very broken to me: <package pkgid="c3442e30a9ca21f9875809d4891e4d4dbc7dcada" name="tk" arch="i386"><version epoch="0" ver="8.4.13" rel="1"/><file>tk-8.3.5-tclm4- soname.patch</file><file>tk-8.4-no_rpath.patch</file><file>tk-8.4.13-autoconf. patch</file><file>tk-8.4.4-lib-perm.patch</file><file>tk.spec</file><file>tk8.4. 13-src.tar.gz</file></package> Ever tried to upgrade from i386.rpm to a src.rpm? :) Version-Release number of selected component (if applicable): createrepo-0.4.4-1 How reproducible: Everytime, just run createrepo when you've got src.rpms and i386.rpms within a (sub-)directory accessed by createrepo. After removing src.rpms and re-executing of createrepo the repodata stuff seems to be correct. Actual results: createrepo creates broken repodata. Expected results: Working repodata again - even when src.rpm and i386.rpm files are in the same (sub-)directory.
Technically the src.rpm has RPMTAG_ARCH set - try it: rpm -qp --qf '%{arch}\n' dummy-1.0-1.src.rpm i386 This is why the convention has been to keep src.rpm repos seperate for fedora. The way to identify a src.rpm is the absence of sourcerpm filed. rpm -qp --qf '%{sourcerpm}\n' dummy-1.0-1.src.rpm (none)
But the stuff worked with older versions of createrepo...
If you let me know which version we regress from I'll look into. Particularly with xml fragment, etc.
Created attachment 131777 [details] Proposed patch Hmm are you using rpm >= 4.4.6? If so see CHANGES for why this broke - attached createrepo patch will work around. Please in future if you are using non-standard core packages mention this in the bug report. Please test this and I'll commit upstream (it looks logically correct to me).
Oops...yes I am - sorry. And yes your patch works, of course and looks sane, too. Thank you very much for resolving it anyway :)
Commited to upstream createrepo.