[FAILED] Network/Termius - Unresolvable (Have Choice For ......) | OBS
Hello, What is constantly wrong about Termius (and some other) builds using Open Build Service ?_? Those Unresolvable situations happen constantly on daily basis within OBS ! What am I supposed to do with my Home (home:MartinVonReichenberg:Network/Termius and Network/Winbox) 'repositories' ?_? It is so goddamn common even if you want/need to build a very simple package . . . Thanks for acknowledging & fixing the issue. Best regards, Martin from Liberec, Czechia Sent with Proton Mail secure email.
Hi Martin, "Martin von Reichenberg" <martin.von.reichenberg@protonmail.com> writes:
Hello, What is constantly wrong about Termius (and some other) builds using Open Build Service ?_?
The problem in this case Termius: it ships a whole lot of libraries in %_libdir because you've wildcarded %_libdir in %files into which you've copied a bunch of stuff from /opt/ in line 69: --8<---------------cut here---------------start------------->8--- cp -a "%{_builddir}/%{name}-%{version}/opt/%{name}/" "%{buildroot}/%{_libdir}/" --8<---------------cut here---------------end--------------->8--- I guess that the upstream Termius package bundles every shared library under the sun and now your rpm ships all of them. Thereby it will conflict with most of your system libraries and installing it, will very likely wreck your OS. Now, why are you seeing this error? OBS' dependency resolver is intentionally pretty dumb, it will refuse to resolve any ambiguities and require the user to define a choice (for reproducibility). Since your own rpm ships a lot of shared libraries, it now introduces such an ambiguity: OBS doesn't know whether it should use libz from Termius or from the libz package in Leap/Tumbleweed. There's an easy workaround, add `Prefer: -Termius` to the prjconf and then OBS will never prefer shared libraries from Termius for builds if there is an ambiguity. *But* you shouldn't do that. You should fix the rpm to not ship system libraries, because that might have a dangerous impact on the system where it gets installed (if it will even install). Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstr. 146 90461 Nürnberg Germany www.suse.com Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
Thank you, Solved with `osc meta prjconf -F ./Termius.prjconf` which is not mentioned anywhere . . . . . . . . . . . Best regards, Martin from Liberec, Czechia Sent with Proton Mail secure email. On Saturday, June 15th, 2024 at 17:18, Dan Čermák <dcermak@suse.com> wrote:
Hi Martin,
"Martin von Reichenberg" martin.von.reichenberg@protonmail.com writes:
Hello, What is constantly wrong about Termius (and some other) builds using Open Build Service ?_?
The problem in this case Termius: it ships a whole lot of libraries in %_libdir because you've wildcarded %_libdir in %files into which you've copied a bunch of stuff from /opt/ in line 69: --8<---------------cut here---------------start------------->8---
cp -a "%{_builddir}/%{name}-%{version}/opt/%{name}/" "%{buildroot}/%{_libdir}/" --8<---------------cut here---------------end--------------->8---
I guess that the upstream Termius package bundles every shared library under the sun and now your rpm ships all of them. Thereby it will conflict with most of your system libraries and installing it, will very likely wreck your OS.
Now, why are you seeing this error? OBS' dependency resolver is intentionally pretty dumb, it will refuse to resolve any ambiguities and require the user to define a choice (for reproducibility). Since your own rpm ships a lot of shared libraries, it now introduces such an ambiguity: OBS doesn't know whether it should use libz from Termius or from the libz package in Leap/Tumbleweed.
There's an easy workaround, add `Prefer: -Termius` to the prjconf and then OBS will never prefer shared libraries from Termius for builds if there is an ambiguity. But you shouldn't do that. You should fix the rpm to not ship system libraries, because that might have a dangerous impact on the system where it gets installed (if it will even install).
Cheers,
Dan
-- Dan Čermák dcermak@suse.com
Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstr. 146 90461 Nürnberg Germany
www.suse.com Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
participants (2)
-
Dan Čermák -
Martin von Reichenberg