Bug 130590 - unsigned package not re-fetched from file:// yum repo after signing
unsigned package not re-fetched from file:// yum repo after signing
Product: Fedora
Classification: Fedora
Component: up2date (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
Depends On:
  Show dependency treegraph
Reported: 2004-08-22 10:12 EDT by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-26 15:47:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2004-08-22 10:12:44 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)

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):

How reproducible:

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 15:47:16 EDT
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

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