| Summary: | Failure to download a package interrupts other simultaneous downloads also | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ankur Sinha (FranciscoD) <sanjay.ankur> |
| Component: | dnf | Assignee: | Zdeněk Pavlas <zpavlas> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | akozumpl, jzeleny, packaging-team-maint, pnemade, rholy, sanjay.ankur |
| 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: | 2013-11-07 13:32:19 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: | |
|
Description
Ankur Sinha (FranciscoD)
2013-11-06 23:03:49 UTC
krb5-libs is required to run the intended transaction, and since dnf was not able to retrieve it, it aborted all downloads. We should correctly resume downloading partial files on the next run. It's very easy to switch the fail-fast vs download-all behavior (there's a librepo option for that), but I'm not convinced the latter is better. When something goes wrong, users usually prefer fast response. Why do you want to continue downloading in this case? (In reply to Zdeněk Pavlas from comment #1) > krb5-libs is required to run the intended transaction, and since dnf was not > able to retrieve it, it aborted all downloads. We should correctly resume > downloading partial files on the next run. > > It's very easy to switch the fail-fast vs download-all behavior (there's a > librepo option for that), but I'm not convinced the latter is better. When > something goes wrong, users usually prefer fast response. Why do you want to > continue downloading in this case? Hrm. Well, I just thought that the krb5-libs package has no connection to the kernel or gimp packages and therefore, they should continue downloading. I just find it logical, I guess. I think this is what yum did: it listed packages it failed to download at the end. On giving users the error as quickly as possible, is that a policy dnf upstream is adopting for *all* issues? For instance, in https://bugzilla.redhat.com/show_bug.cgi?id=910133 if the user is to be told of an error asap, he should be told he lacks permissions right at the start of the transaction. Rather, in this bug, dnf downlaods everything and spews out the error right at the end. I didn't know that this behaviour is intended. You can close the bug as wontfix if dnf upstream thinks this is preferred. Thanks, Warm regards, Ankur > Well, I just thought that the krb5-libs package has no connection to the kernel or gimp packages and therefore, they should continue downloading. You're right, they are unrelated. But "dnf update" puts all updates into a single transaction. We won't update anything regardless of the early/late failure mode. It affects only the amount of data downloaded, not the net result. > You can close the bug as wontfix if dnf upstream thinks this is preferred. Wontfix? As I said, "fixing" it is really easy, just set failfast=False when calling librepo.download_packages(). notabug seems more appropriate. (In reply to Zdeněk Pavlas from comment #3) > > Well, I just thought that the krb5-libs package has no connection to the kernel or gimp packages and therefore, they should continue downloading. > > You're right, they are unrelated. But "dnf update" puts all updates into a > single transaction. We won't update anything regardless of the early/late > failure mode. It affects only the amount of data downloaded, not the net > result. Aye. It's more about expected behaviour, just like the other bug I've cited. > > > You can close the bug as wontfix if dnf upstream thinks this is preferred. > > Wontfix? As I said, "fixing" it is really easy, just set failfast=False when > calling librepo.download_packages(). notabug seems more appropriate. Sure. |