Re: About GNUrl and cURL

Martin Schanzenbach <[email protected]> Wed, 07 Sep 2022 06:33:05 +0000
Newsgroups	gmane.network.gnunet.devel
Message-ID	<1662532325-sup-7779@werkbank>
FYI I updated the detection logic again. You may check if that works for
you know.
Know that even if it detected "curl-openssl" for you the last time, it
probably was correctly linked against the "drop-in" libcurl-gnutls.
We just were not able to detect that.

BR

Excerpts from Martin Schanzenbach's message of 2022-09-07 06:06:52 +0000:
> Excerpts from madmurphy's message of 2022-09-06 22:17:53 +0100:
> > Okay, about the libcurl-gnutls package, Martin was right. If I add this
> > line to the PKGBUILD of that package,
> > 
> > ln -s libcurl-gnutls.so.4.8.0 "${pkgdir}"/usr/lib/libcurl-gnutls.so
> > 
> > Everything goes well in GNUnet and the configure script prints
> > 
> > ...
> > HTTP Client:                    curl-gnutls
> > ...
> > 
> > Now the question is what to do. In theory I could publish my own version of
> > libcurl-gnutls on AUR with only that line added, and make GNUnet depend on
> > it. But I wonder why Arch developers did that. My guess is that for
> > creating the libcurl-gnutls package they copied and hacked the section of
> > the PKGBUILD that builds libcurl-compat
> > <https://archlinux.org/packages/core/x86_64/libcurl-compat/>, which is a
> > glue package that also does not ship the unversioned .so file
> > <https://archlinux.org/packages/core/x86_64/libcurl-compat/files/>. Who
> > knows…
> > 
> 
> Ah look here: https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> The curl-compat package does link libcurl.so against the versioned
> files.
> And curl-gnutls does the same: https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> 
> So, this would actually confirm my initial thoughts that those are
> drop-in replacements and that we should not check for libcurl-gnutls at
> all.
> I have no idea how to "detect" the version of curl in this case.
> But, I also do not think it really matters.
> So maybe we should just remove the logic that tries to identify the curl
> version.
> 
> > Jacki, what do you suggest? The PKGBUILD of libcurl-gnutls attached to this
> > email works well for GNUnet. But for publishing on AUR we would need to
> > rename it in some way.
> > 
> > --madmurphy
> > 
> > On Tue, Sep 6, 2022 at 9:06 PM Martin Schanzenbach <[email protected]>
> > wrote:
> > 
> > > Excerpts from Christian Grothoff's message of 2022-09-06 21:34:45 +0200:
> > > > On 9/6/22 14:43, madmurphy wrote:
> > > > > Just out of curiosity, why do I get
> > > > >
> > > > > gstreamer:                      no
> > > >
> > > > You need also certain related gstreamer libraries
> > > > (gstreamer-plugins-base or something like that) before gstreamer is
> > > > considered "complete enough" to work for GNUnet.
> > > >
> > >
> > > I have to disagree that this is what configure.ac checks. I invite you
> > > to investigate as well. I am at a loss as what exactly the logic
> > > currently is. It sais "gstreamer no" for me, too, but conversation is
> > > built with the "gst" "backend". Whatever that means. Anyway.
> > >
> > > > -Christian
> > >
signature.asc (application/pgp-signature, 833 B)