Bug 727586
| Summary: | repodiff uses stale metadata cache in subsequent runs | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | James Antill <james.antill> |
| Component: | yum | Assignee: | James Antill <james.antill> |
| Status: | CLOSED ERRATA | QA Contact: | Red Hat Satellite QA List <satqe-list> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.3 | CC: | ksrot |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | yum-3.2.29-18.el6 | Doc Type: | Bug Fix |
| Doc Text: |
Previously, the repodiff utility used a stale metadata cache in subsequent runs. When two repodiff commands were executed in succession, the second run reused cached data from the first. This bug has been fixed and repodiff now properly validates the metadata if a connection cannot be established or the cached data are about to be reused.
|
Story Points: | --- |
| Clone Of: | 709972 | Environment: | |
| Last Closed: | 2011-12-06 17:34:47 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: | |||
| Bug Depends On: | 665919, 709972 | ||
| Bug Blocks: | |||
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1702.html |
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Previously, the repodiff utility used a stale metadata cache in subsequent runs. When two repodiff commands were executed in succession, the second run reused cached data from the first. This bug has been fixed and repodiff now properly validates the metadata if a connection cannot be established or the cached data are about to be reused.