-
Notifications
You must be signed in to change notification settings - Fork 8.3k
libcurl dependency on openSUSE #6184
Copy link
Copy link
Closed
Labels
Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifResolution-ExternalThe issue is caused by external component(s).The issue is caused by external component(s).Resolution-FixedThe issue is fixed.The issue is fixed.
Metadata
Metadata
Assignees
Labels
Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifResolution-ExternalThe issue is caused by external component(s).The issue is caused by external component(s).Resolution-FixedThe issue is fixed.The issue is fixed.
From
docs/installation/linux.md:If the intention is that the user should choose the
break powershell-6.0.1-1.rhel.7.x86_64 by ignoring some of its dependenciesoption, then describing the option text explicitly ("Choose the solution to ignore dependencies and install the package anyway.") would be better. I don't believe zypper has to deterministically give that one as "Solution 2" and it's a vague instruction anyway.It would be better to tell users to run
zypper search --provides --match-exact '/usr/lib64/libcurl.so.4'instead of justzypper search libcurlto verify that they have the required library. The current command finds all packages that havelibcurlin the name. While it's obvious which package the user should be looking for, there's no reason to be vague about it.I assume this situation happens because you reuse the RHEL package for openSUSE and RHEL's libcurl package provides "libcurl". Why not make a separate package for openSUSE that requires "libcurl4" so that this workaround is not needed in the first place?