Bug 199228 - createrepo-0.4.4-0.1 is non-functional
Summary: createrepo-0.4.4-0.1 is non-functional
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: createrepo
Version: 5
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-07-18 06:01 UTC by Ralf Corsepius
Modified: 2014-01-21 22:54 UTC (History)
3 users (show)

Fixed In Version: 0.4.4-0.2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-14 20:53:01 UTC
Type: ---
Embargoed:


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

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.



 


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