http://bugzilla.novell.com/show_bug.cgi?id=597577 http://bugzilla.novell.com/show_bug.cgi?id=597577#c0 Summary: libzypp: after download problem, half-updated multi-rpm components could be left broken Classification: openSUSE Product: openSUSE 11.1 Version: Final Platform: All OS/Version: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: libzypp AssignedTo: zypp-maintainers@forge.provo.novell.com ReportedBy: Markus.Kuhn@cl.cam.ac.uk QAContact: qa@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.18) Gecko/2010020400 SUSE/3.0.18-0.1.1 Firefox/3.0.18 The observed fact that libzypp installs each individual RPM immediately after it has downloaded it concerns me; first downloading all RPMs before installing them would reduce the risk of being left with a broken, half-updated application. The latter may require more temporary disk space, but would be far more robust if the network is unreliable or one of the later RPMs turns out to be corrupt or missing on the repository. (Microsoft Update seems to do the right thing here, instead.) Reproducible: Didn't try Steps to Reproduce: 1. use "zypper patch", "zypper update", "zypper in", etc. to update a larger component that consists of multiple RPMs that depend of each other (app+library+data), e.g. Firefox 2. unplug the network cable (to simulate a longer network outage, repository corruption, etc.) after the first RPM has already been installed and before the last RPM or diff has been downloaded 3. test the now half-updated component Actual Results: Libzypp currently processes multi-RPM updates in the order download rpm1 install rpm1 download rpm2 install rpm2 If the download of rpm2 fails, the application may be left in a none-usable state. Expected Results: Libzypp should instead download *all* the required rpms onto the local disk before starting installing the first of them: download rpm1 download rpm2 verify presence/integrity/authenticity of *all* required rpms install rpm1 install rpm2 This way, much less can go wrong between the installation of individual rpms and there will be a much lower chance of the system being left in an unusable state. (Ideal would be if updates were applied truly atomically to the file system, but I guess that would require a different file system with transaction semantics, which we don't have yet.) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.