After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 755989 - configure: Add --enable-libssh2 switch and make it independent of Curl
configure: Add --enable-libssh2 switch and make it independent of Curl
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-10-02 15:30 UTC by Carlos Rafael Giani
Modified: 2018-11-03 13:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch for Curl-independent libssh2 configuration (2.01 KB, patch)
2015-10-02 15:32 UTC, Carlos Rafael Giani
rejected Details | Review

Description Carlos Rafael Giani 2015-10-02 15:30:49 UTC
Right now, libssh2 autoconfiguration is tied to Curl's. However, libssh2 is a library generic enough (and SSH support a common enough use case) to move it out of the Curl configure block and let it exist independently. Furthermore, it should be possible to explicitely enable/disable it with an --enable-libssh2 switch.
Comment 1 Carlos Rafael Giani 2015-10-02 15:32:58 UTC
Created attachment 312575 [details] [review]
Patch for Curl-independent libssh2 configuration
Comment 2 Carlos Rafael Giani 2016-08-26 08:32:47 UTC
This still applies to git master. Can this go into 1.9.2 or 1.10?
Comment 3 Tim-Philipp Müller 2016-08-26 11:50:20 UTC
Comment on attachment 312575 [details] [review]
Patch for Curl-independent libssh2 configuration

But why? There's nothing else that uses libssh2 ?

Note also that you left the AM_CONDITIONAL(USE_SSH2, false) at the end intact.
Comment 4 Carlos Rafael Giani 2016-08-26 12:21:52 UTC
True. The reasoning behind this is that curl *may* use libssh2, but libssh2 does not depend on curl and is not related to it in any way. The nested libssh2 check in curl is in my opinion a too strong coupling. It just a bit cleaner to factor out libssh2.

And, the reason why I added a configure switch for libssh2 was that in Yocto, you want to make sure that optional features are switched on/off explicitely through an OpenEmbedded feature called "packageconfig". The way the libssh2 check currently works is that it enables ssh2 support in Curl if libssh2 is present. 

This can lead to indeterministic cross compilation builds. Example:
Given the same build flags and the same build machine, a gst-plugins-bad build on setup A produces a different result than setup B - because something else just happened to build libssh2 earlier.

For this reason, in Yocto, by default, dependency-less GStreamer plugins are enabled, and the others disabled, unless their dependencies are part of openembedded-core. See this for example: http://git.openembedded.org/openembedded-core/tree/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
Comment 5 Ross Burton 2016-09-07 11:59:52 UTC
I second the call for a way to have a determinstic dependency.  The proposed patch defaults to "autodetect" so the out of box experience is identical, but for distributions who want to control what gets built this is essential.
Comment 6 Tim-Philipp Müller 2018-01-20 13:02:17 UTC
I'm fine with adding a switch to explicitly disable/enable libssh use within the curl plugin.

I will accept a patch that does this within the context of the curl check.

I am not going to accept the current patch that puts the ssh check somewhere completely different just because it is theoretically conceivable that in future something else might also use the same lib. We can fix that when the time comes. Until then it's just confusing to have related checks elsewhere.
Comment 7 GStreamer system administrator 2018-11-03 13:41:08 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/308.