http://bugzilla.novell.com/show_bug.cgi?id=492261
Summary: zypper should support --continue or something like it Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: libzypp AssignedTo: zypp-maintainers@forge.provo.novell.com ReportedBy: jnelson-suse@jamponi.net QAContact: qa@suse.de Found By: ---
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.0.7) Gecko/2009022800 SUSE/3.0.7-1.1.6 Firefox/3.0.7
zypper supports -n (--non-interactive) more or less However, any minor download error aborts an entire operation unnecessarily. Not infrequently various mirrors may disconnect or fail to provide for many reasons a file when asked, and this is how zypper currently behaves:
Retrieving package kdebase4-workspace-debuginfo-4.2.2-217.3.x86_64 (10/130), 36.8 M (160.1 M unpacked) Retrieving: kdebase4-workspace-debuginfo-4.2.2-217.3.x86_64.rpm [error] File './x86_64/kdebase4-workspace-debuginfo-4.2.2-217.3.x86_64.rpm' not found on medium 'http://opensuse.ca.unixheads.org/repositories/KDE:/KDE4:/Factory:/Desktop/op...'
Abort, retry, ignore? [A/r/i]: a Failed to provide Package kdebase4-workspace-debuginfo-4.2.2-217.3. Do you want to retry retrieval?
[KDE:KDE4:Factory:Desktop|http://opensuse.ca.unixheads.org/repositories/KDE:/KDE4:/Factory:/Desktop/op...] Can't provide file './x86_64/kdebase4-workspace-debuginfo-4.2.2-217.3.x86_64.rpm' from repository 'KDE:KDE4:Factory:Desktop' History: - File './x86_64/kdebase4-workspace-debuginfo-4.2.2-217.3.x86_64.rpm' not found on medium 'http://opensuse.ca.unixheads.org/repositories/KDE:/KDE4:/Factory:/Desktop/op...'
- Can't provide ./x86_64/kdebase4-workspace-debuginfo-4.2.2-217.3.x86_64.rpm : Media Exception
Abort, retry, ignore? [A/r/i]: a Problem occured during or after installation or removal of packages: Installation aborted by user
Please see the above error message for a hint.
It seems to me that --non-interactive should support a --continue mode where it ignores non-fatal errors and continues.
Reproducible: Always
Steps to Reproduce: 1. 2. 3.
http://bugzilla.novell.com/show_bug.cgi?id=492261
User ma@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=492261#c1
Michael Andres ma@novell.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P4 - Low CC| |jkupec@novell.com, | |ma@novell.com
--- Comment #1 from Michael Andres ma@novell.com 2009-07-31 06:16:50 MDT --- Not being able to get a package that should be installed is a fatal error.
Jano: In conjunction with DownloadInAdvance we could indeed offer to skip those packages, and continue to preload the chache. Installation won't start unless all required packages are present.
http://bugzilla.novell.com/show_bug.cgi?id=492261
User jkupec@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=492261#c2
--- Comment #2 from Ján Kupec jkupec@novell.com 2009-07-31 06:35:03 MDT --- I don't see much benefit in this. What's wrong with simply restarting the operation? You'll need to do that at least once to proceed anyway. Or did you have something else in mind?
If the user wants to run non-interactively e.g. from cron, to get the system updated and avoid failure because of temporary network problem, s/he can repeat the operation in the script until it succeeds.
http://bugzilla.novell.com/show_bug.cgi?id=492261
http://bugzilla.novell.com/show_bug.cgi?id=492261#c3
Michael Andres ma@novell.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX
--- Comment #3 from Michael Andres ma@novell.com 2010-08-04 15:00:43 CEST --- .
http://bugzilla.novell.com/show_bug.cgi?id=492261
http://bugzilla.novell.com/show_bug.cgi?id=492261#c4
Jon Nelson jnelson-suse@jamponi.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |
--- Comment #4 from Jon Nelson jnelson-suse@jamponi.net 2010-08-10 21:26:40 UTC --- I'm reopening this bug because I do feel the functionality is worth having. Frequently, when internet connectivity is poor (as it frequently is for many people) it's convenient to be able to ignore failed or bad downloads (like checksum failures). Therefore I'd like to propose a --batch or --continue mode where zypper ignores non-fatal errors and continues on to the next download. Today, todayloading KDE 4.5.0, at least a half-dozen times I had to tell zypper to ignore the error and continue. However, that also meant that I had to sit and observe zypper for over an hour. It seems to me that people that want a --batch or --continue mode are somewhat more advanced users and are willing to live with the *possibility* (unlikely) that couple of failed downloads out of many will hose a system -- especially since a --batch mode would likely report at the end of the operation "Unable to download: foo bar and baz".
Asking the user to simply repeat the operation isn't necessarily a feasible one.
http://bugzilla.novell.com/show_bug.cgi?id=492261
http://bugzilla.novell.com/show_bug.cgi?id=492261#c5
Michael Andres ma@novell.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Priority|P4 - Low |P3 - Medium Status|REOPENED |NEW Component|libzypp |libzypp Product|openSUSE 11.1 |openSUSE 11.3
--- Comment #5 from Michael Andres ma@novell.com 2010-08-11 13:03:08 CEST --- @Jano: No 'sit and observe zypper for over an hour' is IMO a valid usecase.
Unless in DownloadAsNeeded mode, libzypp will not install anything if not all required packages are actually present. So it should be safe if zypper (auto-)skips download errors in those modes.
http://bugzilla.novell.com/show_bug.cgi?id=492261
http://bugzilla.novell.com/show_bug.cgi?id=492261#c6
--- Comment #6 from Jon Nelson jnelson-suse@jamponi.net 2010-08-11 13:42:41 UTC --- While using DownloadAsNeeded (the default) combined with a batch-like mode is very slightly less "safe" (in a real but statistically unlikely way), I've generally found that the other modes all essentially behave like DownloadInAdvance (I've never actually seen DownloadInHeaps behave differently than DownloadInAdvance - although I admit that it's been a month or two since I tried).
Given the scenario I was faced with last night - downloading over 100 packages from a seemingly slow and problematic server (checksum errors) - I would have much preferred to just tell zypper "do what you can" and walk away, come back a hour or two later, and fix anything that went wrong.
Given that most users that would use a batch-like mode are more advanced, it seems to me that such actions are within the realm of expectations.
https://bugzilla.novell.com/show_bug.cgi?id=492261
https://bugzilla.novell.com/show_bug.cgi?id=492261#c7
Ján Kupec jkupec@novell.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |ma@novell.com
--- Comment #7 from Ján Kupec jkupec@novell.com 2010-09-06 10:55:58 UTC --- (In reply to comment #5)
Unless in DownloadAsNeeded mode, libzypp will not install anything if not all required packages are actually present. So it should be safe if zypper (auto-)skips download errors in those modes.
But quit after downloading, if there were errors? Is this possible from out of zypp? Will it work with keeppackages=0?
https://bugzilla.novell.com/show_bug.cgi?id=492261
https://bugzilla.novell.com/show_bug.cgi?id=492261#c8
Michael Andres ma@novell.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|ma@novell.com |
--- Comment #8 from Michael Andres ma@novell.com 2010-09-06 13:09:03 CEST --- It should. Downloading leaves the package in the cache until it actually gets installed. Only the attempt to install will remove it if 'keeppackages=0'.
(yes, you may have a nonempty cache even if 'keeppackages=0')
https://bugzilla.novell.com/show_bug.cgi?id=492261
https://bugzilla.novell.com/show_bug.cgi?id=492261#c9
--- Comment #9 from Jon Nelson jnelson-suse@jamponi.net 2013-01-24 01:59:35 UTC --- Zypper has changed a *lot* since this bug was filed. Is this bug even valid any more?
https://bugzilla.novell.com/show_bug.cgi?id=492261
https://bugzilla.novell.com/show_bug.cgi?id=492261#c10
Michael Andres ma@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|Normal |Enhancement
--- Comment #10 from Michael Andres ma@suse.com 2013-01-24 11:31:39 CET --- There's still no --continue option which would cause to download as much as possible if used together with --non-interactive.
http://bugzilla.novell.com/show_bug.cgi?id=492261
Björn Voigt bjoernv@arcor.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bjoernv@arcor.de
http://bugzilla.novell.com/show_bug.cgi?id=492261
Eberhard Kümmerle E.Kuemmerle@fz-juelich.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |E.Kuemmerle@fz-juelich.de
--- Comment #11 from Eberhard Kümmerle E.Kuemmerle@fz-juelich.de --- I'm managing a number of desktop systems and I use cron.daily/opensuse.org-online_update to patch them.
Currently, this fails because a minor important repository is not available:
File '/repodata/repomd.xml' not found on medium 'http://download.videolan.org/pub/videolan/vlc/SuSE/13.2'
Abort, retry, ignore? [a/r/i/? shows all options] (a): ABORT request: Aborting requested by user
I would indeed very much appreciate if the major updates from the opensuse repo would still be installed automatically in such a situation.
So I think some kind of --continue or --ignore-minor-errors would be very helpful here!
http://bugzilla.novell.com/show_bug.cgi?id=492261
Michael Andres ma@suse.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FEATURE
--- Comment #12 from Michael Andres ma@suse.com --- The problem with this is, that zypper does not know whether this is a minor or major important repo to you.
If a repo is disabled/skipped, packages previously installed from this repo are considered as 'orphanded'. Orphanded packages involved in any dependency issue may be silently deleted by the resolver. As zypper can't decide whether this would be OK for you, we don't offer such an option.
For your usecase we had to introduce a new repo property which allows you to tag a repo as 'minor important'. Zypper may then ignore the refresh error and continue using the old (unrefreshed) data.
This way one could wait for a repo to become available again rather than permanently disabling it.
I added this as a feature request at https://github.com/openSUSE/zypper/issues/56.
http://bugzilla.novell.com/show_bug.cgi?id=492261
--- Comment #13 from Eberhard Kümmerle E.Kuemmerle@fz-juelich.de --- For those, who want an immediate solution and accept the risks described by Michael Andres:
I wrote the following script 'zypper-ignore-errors' that calls zypper in interactive mode and provides the needed answers automatically:
################## #!/usr/bin/perl
use Expect; # needs package 'perl-Expect' use strict;
my $exp = Expect->spawn('zypper', @ARGV); while ($exp->expect(36000, [ qr|Abort, retry, ignore? [a/r/i.*):|, sub {$exp->send("i\n");}], [ qr|Do you want to disable the repository .* permanently?|, sub {$exp->send("no\n");}], [ qr|? [.*):|, sub {$exp->send("\n");}] )) {} ##################
You can call it like that (important: WITHOUT --non-interactive): zypper-ignore-errors --quiet up -t patch --auto-agree-with-licenses
Best regards, Eberhard