Bug 199228 - createrepo-0.4.4-0.1 is non-functional
createrepo-0.4.4-0.1 is non-functional
Product: Fedora
Classification: Fedora
Component: createrepo (Show other bugs)
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Paul Nasrat
Depends On:
  Show dependency treegraph
Reported: 2006-07-18 02:01 EDT by Ralf Corsepius
Modified: 2014-01-21 17:54 EST (History)
3 users (show)

See Also:
Fixed In Version: 0.4.4-0.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-14 16:53:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed patch (527 bytes, patch)
2006-07-19 06:40 EDT, Paul Nasrat
no flags Details | Diff

  None (edit)
Description Ralf Corsepius 2006-07-18 02:01:24 EDT
Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:

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:

Additional info:
This createrepo is completely non-functional
Comment 1 Tomasz Kepczynski 2006-07-19 02:28:15 EDT
I have the same problem. Giving it the full path (starting with /)
seems to work.
Comment 2 Paul Nasrat 2006-07-19 06:40:43 EDT
Created attachment 132672 [details]
Proposed patch

Can you try and see if this patch works for you
Comment 3 Ralf Corsepius 2006-07-19 07:30:39 EDT
(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.

Comment 4 Paul Nasrat 2006-07-19 07:34:35 EDT
Yeah the patch was from CVS HEAD, sorry.  I'll spin new packages and commit
Comment 5 Fedora Update System 2006-08-14 15:58:18 EDT
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.
Comment 6 Ralf Corsepius 2006-08-14 23:28:57 EDT
Thank you for ignoring the package guidelines, esp.

f13, spot, we urgently need a means to enforce the guidelines in Core.
Comment 7 Tom "spot" Callaway 2006-08-14 23:41:48 EDT
I'm not sure I follow. What guidelines are being violated here?
Comment 8 Jesse Keating 2006-08-14 23:44:15 EDT
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
Comment 9 Ralf Corsepius 2006-08-15 00:45:16 EDT
(In reply to comment #7)
> I'm not sure I follow. What guidelines are being violated here?

The FPC had agreed upon:
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

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.


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