Mailinglist Archive: opensuse-bugs (10759 mails)
| < Previous | Next > |
[Bug 540587] If Yast MUST NOT kill SQUID in middle of system update!
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Thu, 22 Oct 2009 10:49:05 -0600
- Message-id: <20091022164905.9C658245517@xxxxxxxxxxxxxxxxxxxxxx>
http://bugzilla.novell.com/show_bug.cgi?id=540587
User suse@xxxxxxxxx added comment
http://bugzilla.novell.com/show_bug.cgi?id=540587#c16
--- Comment #16 from L. A. Walsh <suse@xxxxxxxxx> 2009-10-22 09:48:59 PDT ---
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.
User suse@xxxxxxxxx added comment
http://bugzilla.novell.com/show_bug.cgi?id=540587#c16
--- Comment #16 from L. A. Walsh <suse@xxxxxxxxx> 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.
| < Previous | Next > |