Hi Martin, That means, if you can find out how the packages linked against libcurl-compat or libcurl-gnutls are built from source, you can do the same with the gnunet package.
The packages in the official repositories that explicitly require libcurl-gnutls (and not simply libcurl) are spotify-launcher <https://archlinux.org/packages/community/x86_64/spotify-launcher/> ( PKGBUILD <https://github.com/archlinux/svntogit-community/blob/packages/spotify-launcher/trunk/PKGBUILD> / package source code <https://github.com/kpcyrd/spotify-launcher/archive/refs/tags/v0.3.0.tar.gz>) and steam-native-runtime <https://archlinux.org/packages/multilib/x86_64/steam-native-runtime/> ( PKGBUILD <https://github.com/archlinux/svntogit-community/blob/packages/steam-native-runtime/trunk/PKGBUILD> / no source code here, it's just glue). But it is a mystery to me how they would find out. 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 That libcurl-compat package compiles curl with different build settings, then renames libcurl.so.4.8.0 to libcurl-compat.so.4.8.0, and finally links libcurl.so.3, libcurl.so.4.0.0, libcurl.so.4.1.0, libcurl.so.4.2.0, libcurl.so.4.3.0, libcurl.so.4.4.0, libcurl.so.4.5.0, libcurl.so.4.6.0, libcurl.so.4.7.0 to libcurl-compat.so.4.8.0 (these version are all old versions, and the files libcurl.so, libcurl.so.4 and libcurl.so.4.8.0 remain linked to the binary shipped by the original curl package). That libcurl-gnutls package does exactly the same, but the basename of the symlinks becomes libcurl-gnutls.so.* instead of simply libcurl.so.*. FYI I updated the detection logic again. You may check if that works for you know. If I try to build the last GNUnet commit <https://git.gnunet.org/gnunet.git/tree/?id=6745bed70af20a11aee5e0c8f6e7bd8479031e9e> with libcurl-gnutls from the official Arch repository I still get ... HTTP Client: curl (OpenSSL) ... while if I use my hacked libcurl-gnutls I get ... HTTP Client: curl-gnutls ... I think I found a solution. I will publish a glue package on AUR named libcurl-gnutls.so, which will depend on the official libcurl-gnutls, and on which GNUnet will depend. All this glue package will do is simply creating an unversioned symlink. --madmurphy On Wed, Sep 7, 2022 at 7:33 AM Martin Schanzenbach <mschanzenb...@posteo.de> wrote: > 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 < > 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 > > > > >
