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…
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 <mschanzenb...@posteo.de>
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
>
curl-7.85.0-1.src.tar.gz
Description: application/gzip
