http://bugzilla.novell.com/show_bug.cgi?id=540587 User suse@tlinx.org added comment http://bugzilla.novell.com/show_bug.cgi?id=540587#c16 --- Comment #16 from L. A. Walsh <suse@tlinx.org> 2009-10-22 09:48:59 PDT ---
It is not related to squid only. It is not related to dup only. It is not related to openSUSE only.
If one of the components required to perfrom the update (rpm, aria, curl, bash, network, ..) breaks during the update, then you are stuck.
There are some differences in the situations you describe. 1) if one is updating a large list of interdependent packages, and downloading as one is installing (which appeared to be the default action(?)) while executing 'yast'(GUI), then one is guaranteed to have a problem if one kills off the network. 2) If it's an update to a released product, it would violate expectations for an incompatible change to be introduced as a patched or updated product. You could make your argument if one was performing a live-upgrade to the next level of product -- in that case, all RPMS needed to perform the upgrade should likely be downloaded ahead of time, and critical packages saved for 'last' where they would be less likely to disrupt the installation. Usually, if incompatible changes are made to config files between _upgrades_ (going between versions), those packages need to be moved last if they are critical to the process AND if the user has modified one of the config files. If the config files are in the standard state (unmodified), it should be safe to upgrade that package with its upgraded options. If it's not, then that's a bug in that product. This bug's not about all bugs in all products. It's about not killing off your network infrastructure while you are still using it to download updates that are being interspersed with installs AND to "be careful" about updating packages that are being used as 'infrastructure' so that when a daemon (like squid, in _this_ situation) is restarted, the update process is in a known, idle state so a temporarily dropped connection won't cause a hang, bug can be immediately re-initiated after the package has been _updated_ (within the same release). In the case of squid -- if the update or upgrade process detects it is using a proxy on the same machine that's being updated, it might be prudent to issue a warning and ask if this is intentional -- especially if the proxy is going to be replaced. -- 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.