Description of problem: Version-Release number of selected component (if applicable): 0.4.4-0.1 How reproducible: Deterministic Steps to Reproduce: 1. createrepo <some dir containing rpms> Actual results: # createrepo fedora/5/extra/i386 Directory must exist The directory fedora/5/extra/i386 does exist. This had worked with all previous releases of createrepo Expected results: Function. Additional info: This createrepo is completely non-functional
I have the same problem. Giving it the full path (starting with /) seems to work.
Created attachment 132672 [details] Proposed patch Can you try and see if this patch works for you
(In reply to comment #2) > Created an attachment (id=132672) [edit] > Proposed patch > > Can you try and see if this patch works for you Though the patch doesn't seem to apply to createrepo-0.4.0-0.1, it seems to work.
Yeah the patch was from CVS HEAD, sorry. I'll spin new packages and commit upstream.
createrepo-0.4.4-0.2 has been pushed for fc5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
Thank you for ignoring the package guidelines, esp. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199229 f13, spot, we urgently need a means to enforce the guidelines in Core.
I'm not sure I follow. What guidelines are being violated here?
I think he's complaining about the release string of this package '0.1'. Paul, any reason why we can't bump this to '1' to follow the naming guidelines of whole numbered releases? If it is a snapshot, it'll have to follow the snapshot guidelines.
(In reply to comment #7) > I'm not sure I follow. What guidelines are being violated here? The FPC had agreed upon: <int>%{$dist}<int> with the first int > 0. (In reply to comment #8) > I think he's complaining about the release string of this package '0.1'. Yes, that's the detail I actually was complaining about in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199229 In this particular case, due to the brokenness of createrepo, I had to resort to packaging an upstream snapshot and had been confronted with the question of "which release tag to choose, such that a future (== 0.2) FC update will replace my local package". A leading 0 closes out 0.<date>%{?dist}, because 0.2 will always be 0.<date>. Not using an <int> as first number closes out appending ".<number>", because one can never be sure if Core will not append a conflicting number. In this particular case, I am now trapped in me having used 0.20060730%{?dist} and RH using 0.2.