It would appear that on Sep 19, Carlos E. R. did say:
On Monday, 2011-09-19 at 04:03 -0400, Joe(theWordy)Philbrook wrote:
I would stay clear of zypper dup, unless you really understand what it does, or if you use it to change distro version.
Yeah, I used to feel that way, but gradually the list of files that it bothered to say wouldn't be upgraded, by "zypper up" became too large for comfort. I don't know what percentage was for "vendor changes" but zypper dup got my 11.3 as up to date as possible. Which might have helped when I used it to upgrade to 11.4...
That's the wrong way of thinking.
No what would be the wrong way of thinking for *_ME_* would be to think like anybody besides myself...
If zypper up will not upgrade something it is because the rules you have set impede it, so what it says will do is the correct thing.
Agreed if the in-place "rules" for it's behavior impede it's upgrading a package then it is doing the correct thing. It's serving to alert me that there may be an issue that needs resolving for a more complete upgrade.
What you have to do is change the rules.
Or change the method. Especially if I don't know which rule that I myself didn't craft is impeding the results I'm looking for... I did mention I'm keeping multiple distros up to date... Even if I was smart enough to customize the default "rules" for each distro's package management, I wouldn't likely have the time... In any case "I" never set any "rules" for zypper (except for an occasional "lock" which I never leave in place long enough to forget it's there.) {Of course, if it was possible to set a negative lock to tell zypper to NEVER install a particular package, I'd have simply set a permanent lock to "rule" out iced-tea some time ago...} * quoted excerpts from "man zypper" => update (up) [options] [packagename] ... => Update installed packages with newer versions, where possible. => => This command will not update packages which would require change => of package vendor unless the vendor is specified in => /etc/zypp/vendors.d, or which would require manual resolution of => problems with dependencies. Such non-installable updates will => then be listed in separate section of the summary as "The fol- => lowing package updates will NOT be installed:". I don't have it in me to track all the vendor changes to keep a viable venders.d file updated. Nor to second guess the dependencies issues that would require "manual intervention". If I see one or two particularly desired upgrade(s) listed under "will NOT be installed" I might abort and try a direct install command to see what {up/down}grades, and removes, would be triggered by the ones I care about. But would otherwise tend to ignore the list until it became too large for my comfort. At which point the quick fix is to {provisionally} use a bigger hammer: => dist-upgrade (dup) [options] => Perform a distribution upgrade. This command applies the state => of (specified) repositories onto the system; upgrades (or even => downgrades) installed packages to versions found in reposito- => ries, removes packages that are no longer in the repositories => and pose a dependency problem for the upgrade, handles package => splits and renames, etc. Paying close attention to what (if anything) would be "removed" to bring my system more fully in sync with the current repo defaults. If I don't like the changes it would make then I might go back to "zypper up" until I can find the time to figure out some "manual intervention"... Any way that's the way my brain resolves such issues... But thanks for the advice. && Have a 'nice' day. -- | --- ___ | <0> <-> Joe (theWordy) Philbrook | ^ J(tWdy)P | ~\___/~ <<jtwdyp@ttlc.net>> -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org