Repository navigation
libcurl dependency on openSUSE #6184
Description
Activity
Perhaps we'll use .Net Core 2.1 in the next release and the behavior can be changed.
Ilya (@iSazonov) are they for sure going to have the managed HTTP solution baked into .NET Core 2.1.x? I tried to figure out where they were at on that, but was only able to find vague mentions of it.
I will be very happy to be rid of this painful relationship with libcurl.Reacted by Greg ZimmermanI believe we could ask them directly about managed httpclient. Previously I saw md file about this.
I also saw a recent PR which makes searching for *.so more reliable.(Note that (1) and (2) are doc fixes and could be done now.)
Arnav Singh (@Arnavion) Feel free to create PR.
Opened a PR.
Reacted by IlyaPerhaps we'll use .Net Core 2.1 in the next release and the behavior can be changed.
are they for sure going to have the managed HTTP solution baked into .NET Core 2.1.x? I tried to figure out where they were at on that, but was only able to find vague mentions of it.
FYI, the blog post for 2.1.300-preview2 says it has the managed HTTP implementation.
Arnav Singh (@Arnavion) Thanks for the reference! It is good news.
Dongbo Wang (@daxian-dbw) Steve Lee (@SteveL-MSFT) .Net Core 2.1 Preview2 is released. Seems they fixed tons bugs. Is we ready to migrate?
I think we should move to Preview2 before our next 6.1 Preview release
Tracking Issue #6632
Since the 2.1 port was done and 2.1 was released today, I assume it's final that the next PS major release will use it? If so, should this issue target 1) removing the libcurl required dependency from the RHEL rpm package, and 2) removing the note in the OP from the docs?
Arnav Singh (@Arnavion) We is already on 2.1 RC1 :-) And yes, next release will be on 2.1.
We have to review our packaging and doc. Feel free to contribute!
I believe docs should be updated for only new version 6.1 not 6.0.- added a commit that references this issue
on Aug 6, 2018 This is done now.
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?