Bug 1399235
| Summary: | yum reposync fails to download rpms that already exist in the repo | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Nadav Goldin <ngoldin> |
| Component: | yum-utils | Assignee: | Michal Domonkos <mdomonko> |
| Status: | CLOSED DUPLICATE | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.2 | CC: | dcaroest, eedri, extras-qa, ngoldin, nicolas, packaging-team-maint, tim.lauridsen, vmukhame |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1332441 | Environment: | |
| Last Closed: | 2017-01-11 17:08:53 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Nadav Goldin
2016-11-28 15:31:52 UTC
I am able to reproduce this issue locally with createrepo/reposync: Assume 'remote_repo' serves a RPM named 'dummy-something.rpm' with 'Release=1' field. Run reposync, then recreate the RPM with the exact same spec file, except 'Release=2' field, keeping the exact same filename and rebuild the yum repository(with createrepo). Running reposync again will fail with: [Errno 256] No more mirrors to try. I know its not the best practice to keep the same RPM filename for different releases, however MANY packages do so(like python-ioprocess). Moreover, the error message indicates nothing of the true error. I think the expected should be that the latest RPM(the one with 'Release=2' in the example) should be downloaded, like yum would behave. Steps to reproduce locally: 1. create a dummy spec file cat dummy.spec >Name: dummy-rpm Version: 1.0 Release: 1 Summary: dummy summary License: Public domain %description test-reposync-failure %install %files %changelog 2. build the RPM 3. run createrepo on the RPM's directory. 4. run reposync with the local repository configured(here it is /home/ngoldin/tmp/reposync-bz/remote_repo/el7) >cat reposync-config.repo [main] reposdir=/etc/reposync.repos.d [test-reposync] name=test reposync baseurl=file:///home/ngoldin/tmp/reposync-bz/remote_repo/el7 enabled=1 gpgcheck=0 > reposync --config=reposync-config.repo --download_path=/home/ngoldin/tmp/reposync-bz/local_sync 5. re-generate the rpm with 'Release=2'(and keeping the same filename) >rpm -qip dummy-rpm-1.0-1.el7.x86_64.rpm Name : dummy-rpm Version : 1.0 Release : 2 ... Summary : dummy summary Description : test-reposync-failure 5. Regenerate the local repo with createrepo. 6. Run reposync again and see the failure: >reposync --config=reposync-config.repo --download_path=/home/ngoldin/tmp/reposync-bz/local_sync dummy-rpm-1.0-1.el7.x86_64.rp FAILED ... dummy-rpm-1.0-2.el7.x86_64: [Errno 256] No more mirrors to try. (In reply to Nadav Goldin from comment #1) > I am able to reproduce this issue locally with createrepo/reposync: > Assume 'remote_repo' serves a RPM named 'dummy-something.rpm' with > 'Release=1' field. > Run reposync, then recreate the RPM with the exact same spec file, > except 'Release=2' field, keeping the exact same filename and rebuild > the yum repository(with createrepo). Running reposync again will fail with: > [Errno 256] No more mirrors to try. Actually, we seem to never have supported packages with the same filename but different NEVRA, at least not without issues. So like you said, it's not advisable to use such packages in a yum repo (and, to my knowledge, there's no good reason to do so). Anyway, if you think we should address this somehow, please consider filing a separate BZ. Regarding python-ioprocess, I've checked the SRPM as well as the changelog and didn't find anything unusual, could you please elaborate a bit more on this (esp. in what repos did you encounter such packages?) The bug itself (Comment 0) is caused by the reget feature of urlgrabber; yum (called from reposync) considers an existing package file a partial download and tries to resume the download (that's why deleting the file manually fixes that). We already have such a report, so I'm going to close this as a dupe. *** This bug has been marked as a duplicate of bug 1375514 *** clearing needinfo. |