Bug 199228

Summary: createrepo-0.4.4-0.1 is non-functional
Product: [Fedora] Fedora Reporter: Ralf Corsepius <rc040203>
Component: createrepoAssignee: Paul Nasrat <nobody+pnasrat>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: urgent Docs Contact:
Priority: urgent    
Version: 5CC: dcantrell, tcallawa, tomek
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 0.4.4-0.2 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-14 20:53:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Proposed patch none

Description Ralf Corsepius 2006-07-18 06:01:24 UTC
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

Comment 1 Tomasz Kepczynski 2006-07-19 06:28:15 UTC
I have the same problem. Giving it the full path (starting with /)
seems to work.

Comment 2 Paul Nasrat 2006-07-19 10:40:43 UTC
Created attachment 132672 [details]
Proposed patch

Can you try and see if this patch works for you

Comment 3 Ralf Corsepius 2006-07-19 11:30:39 UTC
(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 11:34:35 UTC
Yeah the patch was from CVS HEAD, sorry.  I'll spin new packages and commit
upstream.

Comment 5 Fedora Update System 2006-08-14 19:58:18 UTC
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-15 03:28:57 UTC
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.

Comment 7 Tom "spot" Callaway 2006-08-15 03:41:48 UTC
I'm not sure I follow. What guidelines are being violated here?

Comment 8 Jesse Keating 2006-08-15 03:44:15 UTC
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.

Comment 9 Ralf Corsepius 2006-08-15 04:45:16 UTC
(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.