http://bugzilla.opensuse.org/show_bug.cgi?id=984778 http://bugzilla.opensuse.org/show_bug.cgi?id=984778#c2 --- Comment #2 from Michael Andres --- Unfortunately the information to 'suggest a reboot' is not tied to a 'package', but to a 'patch'. A 'patch' describes the minimal versions of a bunch of packages which need to be installed in order to fix the issue addressed by the 'patch'. "zypper patch" is the operation which evaluates the patch metadata and which is able to suggest a reboot in the summary, if patch providing this hint was applied (i.e. all mentioned packages were updated accordingly). "zypper up" however is a pure package based operation trying to update each package individually to a higher version. The final result might be similar to "zypper patch", but the approach is different and the patch hints are not available here. @ the "old" kernel is left lying around in /boot Well, it's usually a bad idea to remove the running kernel from disk. That's why obsolete kernel packages are usually removed after reboot. The definition which kernel packages too keep is found in /etc/zypp/zypp.conf (see multiversion.kernels). Default is to keep the latest 2 kernel versions (and the booted one). I'll keep this open as 'enhancement' request. maybe we can teach 'up' to sneak into the patch matadata looking for reboot hints. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=984778 http://bugzilla.opensuse.org/show_bug.cgi?id=984778#c4 Andreas Stieger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEW Summary|zypper (unlike YaST) gives |add option to zypper up to |no reboot warning after |recognize |updating the kernel |reboot_needed,relogin_neede | |d,zypp_restart_needed flags | |in update info, like | |"zypper patch" --- Comment #4 from Andreas Stieger --- The problem here would e detecting which patch was now suddenly implicitly installed. And it is not sufficient that the patch is no longer required, as a dependency solution could switch vendors and do other stuff that installs packages from a repository other than the update repository. Also note that there are three actions to account for: https://github.com/openSUSE/open-build-service/blob/master/docs/api/api/patc... * reboot_needed * relogin_needed * zypp_restart_needed The latter also triggers an installation of the zypper patches prior to all others. All of the above would make "zypper up" all but identical to "patch". :-) I adjusted the summary to reflect the enhancement request. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=984778 http://bugzilla.opensuse.org/show_bug.cgi?id=984778#c6 --- Comment #6 from Michael Andres --- (In reply to Andreas Stieger from comment #4)

All of the above would make "zypper up" all but identical to "patch". :-) I adjusted the summary to reflect the enhancement request.

Even if the result is usually similar, the approach is different: - up: Is a 'best effort' approach. You get the latest version 'if it can be installed without conflicts'. There's no assertion - and no conflicts. - patch: A patch requires minimal package versions to be installed. If it can't be applied because packages are involved in a conflict, the conflict is reported. The enhancement could also include 'zypper patch --update'; an option to 'patch' which combines 'patch' and 'up' (assert patches get applied and update whatever else is possible in one go). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=984778 http://bugzilla.opensuse.org/show_bug.cgi?id=984778#c8 --- Comment #8 from Tony Mechelynck --- oops: "zypper lu && zypper lp" -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=984778 http://bugzilla.opensuse.org/show_bug.cgi?id=984778#c10 Tony Mechelynck changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|x86-64 |All Whiteboard| |[workaround for any OS: see | |comment #9 and 10] OS|openSUSE 42.1 |openSUSE 42.2 --- Comment #10 from Tony Mechelynck --- "zypper lu -t package -t patch" announced an incoming kernel patch, so I tried "zypper up -t patch -t package". Both commands warned me about a necessary reboot, and the update command finished with exit status 102 (ZYPPER_EXIT_INF_REBOOT_NEEDED) so I shall now reboot after making sure that my boot loader points to the new kernel-default. I expect this RFE to be RESOLVED in some forthcoming update for openSUSE Leap 42.2 on all platforms, but of course this workaround applies to any already deployed version of zypper, provided only that it supports multiple -t or --type arguments to the up (update) command. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=984778 http://bugzilla.opensuse.org/show_bug.cgi?id=984778#c12 Michael Andres changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ma@suse.com) | --- Comment #12 from Michael Andres --- JFYI: zypper-1.13.24 supports 'zypper patch --with-update' which will perform a combination of 'patch' and 'up'. This includes suppressing any package updates, if patches for the updatestack need to be applied first. @'zypper up including patches': not per default, because patch installation may raise dependency conflicts, which is not wanted in plain 'zupper up'. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=984778 http://bugzilla.opensuse.org/show_bug.cgi?id=984778#c14 --- Comment #14 from Michael Andres --- (In reply to Tony Mechelynck from comment #13)

(In reply to Michael Andres from comment #12) JFYI: the current zypper version on Leap 42.2 (even with the Update-Test repo enabled) is 1.13.21. I hope the update will appear soon, but in the

In case you want to give it a try: http://download.opensuse.org/repositories/zypp:/SLE-12-SP2-Branch/openSUSE_L... This repo always contains the latest updatestack (libsolv.libzypp/zypper) for SLE12-SP2/Leap-42.2 that has passed the developers test suite - i.e. the candidate for the next maintenance update. Nevertheless a developers repo, which has not yet passed the maintenance QA and does not include dependent packages like yast/packagekit (relevant in case the libzypp ABI would chane). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=984778 http://bugzilla.opensuse.org/show_bug.cgi?id=984778#c17 Tony Mechelynck changed: What |Removed |Added ---------------------------------------------------------------------------- Version|Leap 42.1 |Leap 42.3 Whiteboard|[workaround for any OS: see |[workaround for any OS: see |comment #9 and 10] |comment #9 and 10 and | |comment #17] Flags| |needinfo?(ma@suse.com) OS|openSUSE 42.2 |openSUSE 42.3 --- Comment #17 from Tony Mechelynck --- Michael: You said in comment #3 "Keep it open as an RFE". Now the bug has been closed becaused openSUSE 42.1 is at EOL. Do you want to REOPEN it for 42.3 (or for Factory) as an RFE? In the meantime, adding "-t patch -t package" (or vice-versa) on the command-lines for "zypper lu" and "zypper up" looks to me like a satisfactory solution. However, unlike "zypper patch", "zypper up -t patch -t package" simply skips packages for which there is a conflict, rather than asking the user what to do. I suppose this is intentional. What I do is: if "zypper lu -t package -t patch" reports that a patch needs to be installed but that no package can be upgraded, then I run "zypper patch" to see what the conflict is (so I can report the problem to the appropriate developers and/or to Maintenance). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=984778 http://bugzilla.opensuse.org/show_bug.cgi?id=984778#c19 --- Comment #19 from Tony Mechelynck --- (In reply to Michael Andres from comment #18)

zypper patch --with-update

Additionally try to update all packages not covered by patches. The option is ignored, if the patch command must update the update stack first. Can not be combined with --updatestack-only.

Ah, thanks for drawing my attention to this nice option. Previously I would cancel the update if "zypper up -t package -t patch" showed that one patch required reloading zypper, then run "zypper patch --updatestack-only" followed by "zypper up -t package -t patch". "zypper patch --with-update" is more streamlined (and more foolproof) in that it will do, in effect, either "up -t patch -t package" or "patch --updatestack-only" depending on whether or not a zypper reload is required. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=984778 http://bugzilla.opensuse.org/show_bug.cgi?id=984778#c20 --- Comment #20 from Tony Mechelynck --- yay, it works! (unsurprisingly, I suppose) — even when there are updates but no patches: linux-2iyu:~ # (zypper lu -t package -t patch || echo 'exit status' $? ; date ) 2>&1 |tee -a ~/zypper.log Retrieving repository 'RWTH:Leap-42.3-Packman' metadata [...done] Building repository 'RWTH:Leap-42.3-Packman' cache [....done] Loading repository data... Reading installed packages... Patches No updates found. Package updates S | Repository | Name | Current Version | Available Version | Arch --+------------------------+-------------+----------------------+----------------------+------- v | RWTH:Leap-42.3-Packman | libx264-152 | 0.152svn20180305-2.1 | 0.152svn20180305-3.1 | x86_64 Mon 16 Apr 14:18:57 CEST 2018 linux-2iyu:~ # (zypper patch --with-update || echo 'exit status' $? ; date ) 2>&1 |tee -a ~/zypper.log Loading repository data... Reading installed packages... Resolving package dependencies... The following package is going to be upgraded: libx264-152 1 package to upgrade. Overall download size: 340.2 KiB. Already cached: 0 B. No additional space will be used or freed after the operation. Continue? [y/n/...? shows all options] (y): Retrieving package libx264-152-0.152svn20180305-3.1.x86_64 (1/1), 340.2 KiB (915.9 KiB unpacked) Retrieving: libx264-152-0.152svn20180305-3.1.x86_64.rpm [.done (99.0 KiB/s)] Checking for file conflicts: [...done] (1/1) Installing: libx264-152-0.152svn20180305-3.1.x86_64 [.........done] Mon 16 Apr 14:19:46 CEST 2018 linux-2iyu:~ # -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=984778 http://bugzilla.opensuse.org/show_bug.cgi?id=984778#c22 --- Comment #22 from Tony Mechelynck --- P.S. IMHO the most useful uses of zypper are the following: * man zypper * zypper help * zypper help *command* * zypper info *packagename* * zypper lu -t package -t patch * zypper patch --with-update * zypper --releasever *nn.n* dup * but only after changing the URL (and optionally the name and/or alias: I personally use it in the name but not the alias) of all repository entries in the *.repo files (even Packman if present) so that the openSUSE version is replaced by the text "$releasever" (without the quotes of course) * It is possible (and IMHO less error-prone when tweaking the repositories' description manually, for instance to add $releasever) to have a single .repo file (named, for example, /etc/zypp/repos.d/all.repo) rather than a separate one for each repo, but this is only my own preference, and it admittedly makes the all.repo rather bulky; another user might prefer separate .repo files for this reason. For more complicated package management actions than the above, I find YaST more user-friendly. Again, YMMV. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=984778 http://bugzilla.opensuse.org/show_bug.cgi?id=984778#c25 --- Comment #25 from Tony Mechelynck --- Upgraded yesterday to the current beta or RC of Leap 15.1. zypper version is 1.14.27 and its manpage mentions the needs-rebooting command. It says: No core libraries or services have been updated. Reboot is probably not necessary. and ends with status zero (indeed, ATM my system doesn't need rebooting). Note that it said the same thing at the end of "zypper --releasever=15.1 dup" even though the kernel had been updated as part of the distribution upgrade. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=984778 http://bugzilla.opensuse.org/show_bug.cgi?id=984778#c27 --- Comment #27 from Tony Mechelynck --- (In reply to Benjamin Zeller from comment #26)

If the "needs rebooting" flag was set or not depends on the zypper version that did the upgrade. If you upgraded from a zypper version not having the feature to the one offering it, the flag can not be set.

Ah, I see. I upgraded from whatever version of zypper was present day before yesterday on Leap 15.0, "zypper --releasever=15.1 dup" acted on more than 9000 packages including itself and the kernel, and IIUC it invoked its updated version when finishing, which couldn't see the flag because the earlier version didn't know about it. Thanks for explaining. -- You are receiving this mail because: You are on the CC list for the bug.