| Summary: | media-video/ffmpeg-4.4.3 USE=openssl disables gnutls, description reads in the opposite sense | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Joe Breuer <gentoo> |
| Component: | Current packages | Assignee: | Gentoo Media-video project <media-video> |
| Status: | UNCONFIRMED --- | ||
| Severity: | minor | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Long story short, I was wondering why ffmpeg used by a locally built project from git didn't want to read from HTTPS/I had weird linking issues. Turns out that I had both USE=openssl and USE=gnutls turned on for ffmpeg, and that project I was working on apparently only wants to cooperate with ffmpeg using gnutls. What confused me trying to debug this: Despite the USE flag descriptions (equery u ffmpeg): gnutls: Prefer net-libs/gnutls as SSL/TLS provider (ineffective with USE=-ssl) openssl: Enables dev-libs/openssl support. Adds support for encrypted network protocols (TLS/HTTPS). the ebuild actually prefers openssl over gnutls when both flags are set: ffmpeg-4.4.3.ebuild: [line 426ff] if use openssl ; then myconf+=( --disable-gnutls ) fi I was under the impression (maybe I misremember? NEWS item some day or such?) that, if explicitly USEd, gnutls was supposed to take precedence over openssl. (openssl on ffmpeg was turned on in the first place because an older version of the kodi ebuild required this - yay) I would suggest/prefer to flip the sense of the config check, disabling openssl when gnutls is given. Or, alternatively, fix the description to clearly state that having openssl enabled will disable gnutls.