Bug 1027488 - Failure to download a package interrupts other simultaneous downloads also
Failure to download a package interrupts other simultaneous downloads also
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
20
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Zdeněk Pavlas
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-06 18:03 EST by Ankur Sinha (FranciscoD)
Modified: 2014-02-02 17:29 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-07 08:32:19 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ankur Sinha (FranciscoD) 2013-11-06 18:03:49 EST
Description of problem:
While updating my system using `sudo dnf update`, one of the packages seemed unavailable and could not be downloaded. However, due to this, the other packages that were being properly downloaded in parallel also stopped downloading. Should this be the case?

Version-Release number of selected component (if applicable):
dnf-0.4.6-1.fc20.noarch


How reproducible:
Once till now. Will keep an eye out for it in the future

Steps to Reproduce:
1.sudo dnf update
2.
3.

Actual results:
If a package is not downloaded correctly due to, say, faulty metadata, the packages downloading in parallel with it will also halt when an error is detected

Expected results:
Only download of this one package should halt and be reported at the end of the transaction. The other packages should continue downloading normally. The unavailability of one package should not affect other packages.

Additional info:
Here, the kernel and gimp packages stopped because krb5-libs was unavailable.

Downloading Packages:
[SKIPPED] kernel-modules-extra-3.11.7-300.fc20.x86_64.rpm: Already downloaded
[SKIPPED] google-crosextra-carlito-fonts-1.103-0.1.20130920.fc20.noarch.rpm: Already downloaded
[SKIPPED] google-crosextra-caladea-fonts-1.002-0.1.20130214.fc20.noarch.rpm: Already downloaded
[SKIPPED] firewall-config-0.3.8-1.fc20.noarch.rpm: Already downloaded
[SKIPPED] firewalld-0.3.8-1.fc20.noarch.rpm: Already downloaded
[SKIPPED] gimp-libs-2.8.8-1.fc20.x86_64.rpm: Already downloaded
[SKIPPED] gnome-abrt-0.3.3-2.fc20.x86_64.rpm: Already downloaded
[SKIPPED] gnutls-3.1.16-1.fc20.x86_64.rpm: Already downloaded
[SKIPPED] gnutls-utils-3.1.16-1.fc20.x86_64.rpm: Already downloaded
[SKIPPED] gnutls-devel-3.1.16-1.fc20.x86_64.rpm: Already downloaded
[SKIPPED] gnutls-dane-3.1.16-1.fc20.x86_64.rpm: Already downloaded
[SKIPPED] gnutls-c++-3.1.16-1.fc20.x86_64.rpm: Already downloaded
[SKIPPED] gssdp-0.14.6-1.fc20.x86_64.rpm: Already downloaded
[SKIPPED] gupnp-0.20.8-1.fc20.x86_64.rpm: Already downloaded
[SKIPPED] kernel-headers-3.11.7-300.fc20.x86_64.rpm: Already downloaded
[FAILED] krb5-libs-1.11.3-27.fc20.x86_64.rpm: No more mirrors to try - All mirrors were already tried without success
[FAILED] kernel-3.11.7-300.fc20.x86_64.rpm: Not finished - interrupted by error: Cannot download krb5-libs-1.11.3-27.fc20.x86_64.rpm: All mirrors were tried
[FAILED] gimp-2.8.8-1.fc20.x86_64.rpm: Not finished - interrupted by error: Cannot download krb5-libs-1.11.3-27.fc20.x86_64.rpm: All mirrors were tried
Error Downloading Packages:
  cups-1:1.7.0-4.fc20.x86_64: Not finished
  nautilus-extensions-3.10.1-1.fc20.x86_64: Not finished
  libreoffice-ure-1:4.1.3.2-4.fc20.x86_64: Not finished
  langtable-data-0.0.18-1.fc20.noarch: Not finished
  eclipse-swt-1:4.3.1-11.fc20.x86_64: Not finished
  autocorr-en-1:4.1.3.2-4.fc20.noarch: Not finished
  libreoffice-calc-1:4.1.3.2-4.fc20.x86_64: Not finished
  libreoffice-draw-1:4.1.3.2-4.fc20.x86_64: Not finished
  libodfgen-0.0.3-1.fc20.x86_64: Not finished
  perl-DB_File-1.830-1.fc20.x86_64: Not finished
  libreoffice-impress-1:4.1.3.2-4.fc20.x86_64: Not finished
  anaconda-widgets-20.25.6-1.fc20.x86_64: Not finished
  libreswan-3.6-1.fc20.x86_64: Not finished
  libreoffice-opensymbol-fonts-1:4.1.3.2-4.fc20.noarch: Not finished
  mutter-3.10.1.1-2.fc20.x86_64: Not finished
  langtable-0.0.18-1.fc20.noarch: Not finished
  nautilus-3.10.1-1.fc20.x86_64: Not finished
  anaconda-20.25.6-1.fc20.x86_64: Not finished
  libreoffice-writer-1:4.1.3.2-4.fc20.x86_64: Not finished
  krb5-libs-1.11.3-27.fc20.x86_64: Cannot download, all mirrors were already tried without success
  libreoffice-core-1:4.1.3.2-4.fc20.x86_64: Not finished
  krb5-libs-1.11.3-27.fc20.i686: Not finished
  cups-filesystem-1:1.7.0-4.fc20.noarch: Not finished
  gimp-2:2.8.8-1.fc20.x86_64: Not finished - interrupted by error: Cannot download krb5-libs-1.11.3-27.fc20.x86_64.rpm: All mirrors were tried
  libreoffice-graphicfilter-1:4.1.3.2-4.fc20.x86_64: Not finished
  cups-libs-1:1.7.0-4.fc20.x86_64: Not finished
  kernel-3.11.7-300.fc20.x86_64: Not finished - interrupted by error: Cannot download krb5-libs-1.11.3-27.fc20.x86_64.rpm: All mirrors were tried
  mock-1.1.35-1.fc20.noarch: Not finished
  langtable-python-0.0.18-1.fc20.noarch: Not finished
  libreoffice-pdfimport-1:4.1.3.2-4.fc20.x86_64: Not finished
  libmwaw-0.2.0-1.fc20.x86_64: Not finished
Comment 1 Zdeněk Pavlas 2013-11-07 03:51:46 EST
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?
Comment 2 Ankur Sinha (FranciscoD) 2013-11-07 05:07:53 EST
(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
Comment 3 Zdeněk Pavlas 2013-11-07 05:24:47 EST
> 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.
Comment 4 Ankur Sinha (FranciscoD) 2013-11-07 06:06:28 EST
(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.

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