Carlos E. R. wrote:
On 2010-05-07 15:25, Joachim Schrod wrote:
My question really was above the technical level: What consequences has it for an admin if he chooses to use zypper patch instead of zypper update? I now see several of them:
-- Only openSUSE updates are installed, not from OBS (or other) repos. (Which may be a good or a bad thing, as David's whining about his unwanted MariaDB update shows... ;-))
Well, this is because the OBS maintainers "neglect" to create update patches. They could do.
Yes, I understand. Again, I didn't ask about technical possibilities. I asked about differences that are caused by *policies*, i.e., de-facto results of processes using these technology.
-- zypper patch might update packages from openSUSE that zypper up doesn't touch owing to solver problems, maybe requiring user action to resolve problems.
And the other way round, too.
zypper patch in my system right now does nothing, whereas zypper up wants to update about 40 MB, like openoffice and xine. Now, the problem for me is where are those packages coming from... is the xine coming from packman (good) or from somewhere else (bad)? I can't see that info in the printed output. Maybe it needs a different command line.
zypper list-updates does list repos, that's why I would never issue a zypper up without having seen the according list-updates first. Actually, I have a nightly cron job that does both zypper refresh (I have autorefresh set to false) and zypper list-updates. It proceeds to download the available to-be-installed packages. An email is sent only if output is not identical to the one that appears without any updates available, i.e., only if some error occurs or if updates are available. That establishes a notification of available updates, from which repositories, and uses our Internet bandwidth during the night when nobody else wants to use it.
It is easier for me to fire up YOU, go to selected repos, and tell it to install newer versions if available. It is probably the same as "zypper up", but I can see each one and choose another version or another package, one by one.
That would be too much manual work for my situation. I have to update roughly 8 workstations and 2 servers. Not really that much, but it's not practicable to do that manually on each system. Maybe some words on my process are of interest: I share zypper configuration and packages cache via NFS to all SUSE systems. (That list-updates-and-download cron job is run only on one system, of course.) I wrote a script that does the announced update without questions on all systems; I can trigger that command via menu or keystroke directly from my mail client when I receive the email mentioned above -- which includes repository information. I won't do that if some critical package like kernel or X server is updated that has to be checked first; e.g., if VMware is still working afterwards. Those packages typically get locked, until I or somebody of my staff has time to do the check. There is also an automatic check that compares rpm packages and their versions over all systems and notifies us if some system differ from a reference system. (A list of all installed rpms is made as part of our nightly backups for each system, so that's very easy to do.) Yet another check determines that there exist neither .rpmnew nor .rpmsave files on any system. All in all a process where very few manual work is involved, but not too much automatism happens that could destroy our working systems. One gets an email at available updates (and only then) and one klicks the "do install" button if they're OK. Finished, maybe 5-10 secs for each update. Well, almost, maybe once per 4-6 weeks one has to lock a package and check its functionality or that it doesn't destroy other things before updating it. (Btw, on Debian that works even better, because apt has a hold feature that zypper is missing.) If something goes wrong, Nagios reminds me later due to failed checks. No manual checks either. My process is build around my opinion that humans are good for pattern matching ("is this list of updates one that we can probably install without problems?") and bad at issuing repetitive commands (calling "zypper up on all systems" or "list-updates once per day").
Very interesting. It seems I should add a "check needed patches" action to my zypper-up-based update process, to check if the 2nd case happens.
You can do both actions. First run "patch", which will update most of your base system.
Hmm, probably not. zypper list-patches currently list updates for packages that I have installed from other repositories, where I definitively *don't* want that update. I'll have to try that in a VM and see what happens if I do the patch. Anyhow, thanks for the interesting discussion. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org