Bug 130590

Summary: unsigned package not re-fetched from file:// yum repo after signing
Product: [Fedora] Fedora Reporter: Alexandre Oliva <oliva>
Component: up2dateAssignee: Adrian Likins <alikins>
Status: CLOSED NOTABUG QA Contact: Fanny Augustin <fmoquete>
Severity: low Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-26 19:47:16 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:

Description Alexandre Oliva 2004-08-22 14:12:44 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040809

Description of problem:
If up2date is asked to install a package from a local yum repository,
it will fetch the package and bail out if the package turns out to be
unsigned, leaving the unsigned package in /var/spool/up2date.  If you
then sign the package in the repository and restart `up2date -i
package', it will NOT refetch the package, simply bailing out again
because the package in /var/spool/up2date is not signed correctly. 
For packages downloaded from the network (generally incomplete
downloads), it will refetch.  It would be nice if it would do the same
for packages fetched from file:// yum repos as well.

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

How reproducible:
Always

Steps to Reproduce:
1.Create unsigned package in local (file://) yum repository
2.up2date -i package
3.Sign the package in the yum repository
4.up2date -i package again

Actual Results:  Package will keep on failing signature verification
because it won't be refecthed

Expected Results:  Should be refetched, IMHO

Additional info:

Removing the rpm from /var/spool/up2date is the obvious work around.
Comment 1 Adrian Likins 2004-08-26 19:47:16 UTC 
marking this as NOTABUG... regerenating the yum info
will force the package to download again (the timestamp
and contents of the header.info file is used to
invalidate the cache, instead of doing IF-Last-Modified
fetches on every header/package). 

So, there is a easy workaround for this somewhat 
rare case that I prefer over the other alternatives