Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 423303 - net-misc/curl - add RTMP support
Summary: net-misc/curl - add RTMP support
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Anthony Basile
URL:
Whiteboard:
Keywords: EBUILD, PATCH
Depends on:
Blocks:
 
Reported: 2012-06-24 11:44 UTC by Mao PU
Modified: 2012-07-29 14:46 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
curl supporting rtmp (curl-7.26.0-r1.ebuild,5.94 KB, text/plain)
2012-06-24 11:45 UTC, Mao PU
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mao PU 2012-06-24 11:44:37 UTC
cURL supports RTMP when configured accordingly and media-video/rtmpdump is present.

Reproducible: Always
Comment 1 Mao PU 2012-06-24 11:45:57 UTC
Created attachment 316137 [details]
curl supporting rtmp

The problem from #326549 seems to be gone with >=media-video/rtmpdump-2.3, so the attached ebuild suggests providing a use flag, to enable/disable rtmp support for curl.
Comment 2 Jeroen Roovers (RETIRED) gentoo-dev 2012-06-26 15:10:20 UTC
Comment on attachment 316137 [details]
curl supporting rtmp

--- curl-7.26.0.ebuild  2012-06-05 15:58:21.000000000 +0200
+++ -   2012-06-26 17:10:03.952419282 +0200
@@ -13,12 +13,13 @@
 LICENSE="MIT"
 SLOT="0"
 KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~ppc-aix ~amd64-fbsd ~sparc-fbsd ~x86-fbsd ~x64-freebsd ~x86-freebsd ~hppa-hpux ~ia64-hpux ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
-IUSE="ares idn ipv6 kerberos ldap ssh ssl static-libs test threads"
+IUSE="ares idn ipv6 kerberos ldap rtmp ssh ssl static-libs test threads"
 IUSE="${IUSE} curl_ssl_axtls curl_ssl_cyassl curl_ssl_gnutls curl_ssl_nss +curl_ssl_openssl curl_ssl_polarssl"
 
 #lead to lots of false negatives, bug #285669
 RESTRICT="test"
 
+# according to bug #326549 <rtmpdump-2.3 is broken 
 RDEPEND="ldap? ( net-nds/openldap )
        ssl? (
                curl_ssl_axtls? ( net-libs/axtls app-misc/ca-certificates )
@@ -38,13 +39,13 @@
        idn? ( net-dns/libidn[static-libs?] )
        ares? ( net-dns/c-ares )
        kerberos? ( virtual/krb5 )
+       rtmp? ( >=media-video/rtmpdump-2.3 )
        ssh? ( net-libs/libssh2[static-libs?] )
        sys-libs/zlib"
 
 # ssl providers to be added:
 # fbopenssl  $(use_with spnego)
 
-# rtmpdump ( media-video/rtmpdump )  / --with-librtmp
 # krb4 http://web.mit.edu/kerberos/www/krb4-end-of-life.html
 
 DEPEND="${RDEPEND}
@@ -153,7 +154,7 @@
                $(use_enable ldap) \
                $(use_enable ldap ldaps) \
                --enable-pop3 \
-               --without-librtmp \
+               $(use_enable rtmp librtmp) \
                --enable-rtsp \
                $(use_with ssh libssh2) \
                --enable-smtp \
Comment 3 Anthony Basile gentoo-dev 2012-07-29 14:46:43 UTC
Okay this is in with curl-7.27.0.ebuild, but a few points:

1) <media-video/rtmpdump-2.3 is off the tree, so no need for the version number in the DEPEND

2) media-video/rtmpdump has three possible back end ssl providers: gnutls openssl and polarssl.  I tested and it doesn't seem to be the case that we need the same provider on curl as rtmpdump, so the ebuild I pushed does *not* make this assumption.

If this is wrong, then we'll need to change


    rtmp? ( media-video/rtmpdump )

to

    rtmp? (
        media-video/rtmpdump
        curl_ssl_gnutls? ( media-video/rtmpdump[gnutls] )
        curl_ssl_polarssl? ( media-video/rtmpdump[polarssl] )
        curl_ssl_openssl? ( media-video/rtmpdump[-gnutls,-polarssl,ssl] )
    )


3) It also doesn't seem to be the case that we need to have any ssl provider on rtmpdump if we build curl with one.  Again, the ebuild I pushed makes this assumption.

Please test!  If any of the above are a problem, reopen this but.