I have a third party application (ESET File Security for Linux -
esets-4.5.9.x86_64.rpm) that depends on a file (/usr/lib/gconv/UTF-16.so)
rather than the provider package (glibc-locale-32bit). Everytime the provider
gets updated or reinstalled zypper requires a manual action even if the package
still provides said file afterwards:

$ rpm -qpR esets-4.5.9.x86_64.rpm 
/bin/sh
/bin/sh
/bin/sh
/bin/sh
/bin/sh
/lib/ld-linux.so.2
/usr/bin/awk
/usr/lib/gconv/UTF-16.so
config(esets) = 4.5.9-0
ed
openssl
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1

$ zypper in -f glibc-locale-32bit 
Loading repository data...
Reading installed packages...
Forcing installation of 'glibc-locale-32bit-2.22-16.3.x86_64' from repository
'openSUSE-Leap-42.3-Update'.
Resolving package dependencies...

Problem: esets-4.5.9-0.x86_64 requires /usr/lib/gconv/UTF-16.so, but this
requirement cannot be provided
  deleted providers: glibc-locale-32bit-2.22-16.3.x86_64
 Solution 1: deinstallation of esets-4.5.9-0.x86_64
 Solution 2: do not install glibc-locale-32bit-2.22-16.3.x86_64
 Solution 3: break esets-4.5.9-0.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/3/c] (c):


Solution 3 will not break the package since UTF-16.so is still provided by the
updated provider.
This is usually not an issue but causes issues with automated updates because
we can't set solution 3 as default action afaik (--non-interactive defaults to
(c)ancle).

Is this a normal behavior or should zypper be able solve this dependency or is
the issue with the package and unconventional use of dependencies (file instead
of package)?