[Bug 1093334] New: Zypper not properly resolving dependency when provider is updated
http://bugzilla.opensuse.org/show_bug.cgi?id=1093334 Bug ID: 1093334 Summary: Zypper not properly resolving dependency when provider is updated Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: Other OS: openSUSE 42.3 Status: NEW Severity: Enhancement Priority: P5 - None Component: libzypp Assignee: zypp-maintainers@forge.provo.novell.com Reporter: arnd.oberlaender@gmail.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- 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)? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1093334
http://bugzilla.opensuse.org/show_bug.cgi?id=1093334#c1
--- Comment #1 from Arnd Oberländer
http://bugzilla.opensuse.org/show_bug.cgi?id=1093334
http://bugzilla.opensuse.org/show_bug.cgi?id=1093334#c2
Michael Andres
# Example .spec file
%define fixpackage glibc-locale-32bit
Name: MISSING-FILE-PROVIDES-%{fixpackage} Summary: Work around missing file provides License: nolicense Vendor: local Version: 0 Release: 0 BuildArch: noarch BuildRoot: /tmp/%{name}-%{version}-build
Requires: %{fixpackage} Provides: /usr/lib/gconv/UTF-16.so
%description Work around missing file provides.
%install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT
%files %defattr(-,root,root)
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1093334
http://bugzilla.opensuse.org/show_bug.cgi?id=1093334#c3
Arnd Oberländer
participants (1)
-
bugzilla_noreply@novell.com