https://bugzilla.suse.com/show_bug.cgi?id=1205401 https://bugzilla.suse.com/show_bug.cgi?id=1205401#c6 Stefan Hundhammer <shundhammer@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kanderssen@suse.com Flags| |needinfo?(kanderssen@suse.c | |om) --- Comment #6 from Stefan Hundhammer <shundhammer@suse.com> --- the code to fix this on the fly, but then I realized with the latest changes this isn't so easy anymore: https://github.com/yast/yast-ntp-client/pull/174 This changed the full path of the netconfig executable from /sbin to /usr/sbin. That sounds safer, but it's not: We are submitting YaST:Head (i.e. FACTORY) to SLE-15-SP5 (and thus Leap 15.5) as well. But SLE-15-SP5 still uses the OLD executable paths before the usr-merge, i.e. it's still /sbin/netconfig there. Just changing it to /usr/sbin/netconfig doesn't work in that environment since SLE-15 SPx / Leap 15.x don't have that /sbin -> /usr/sbin symlink; for those, ONLY /sbin is the valid path for all those binaries. We agreed some months ago to avoid all those complications by relying on a safe $PATH and calling external binaries from /bin, /sbin, /usr/bin, /usr/sbin without their path, just the binary name: https://github.com/yast/yast-yast2/blob/master/doc/yast-invoking-external-co... But that means that the new check here https://github.com/yast/yast-ntp-client/blob/master/src/modules/NtpClient.rb... def netconfig? FileUtils.Exists(NETCONFIG_PATH) end also doesn't work that easily anymore; we'll have to check for the binary in both possible locations, /usr/sbin and /sbin; or, more generally, in all of $PATH. And while we are at it, maybe migrate that external call from the aging SCR::Execute(.target.bash, ...) to the new Yast::Execute.on_target!(). Knut, what do you think about this? -- You are receiving this mail because: You are on the CC list for the bug.