x264 listed as a hard dependency, when it could be optional #1

New Issue

farkuhar · 2023-01-27T16:23:35+01:00

farkuhar commented

2023-01-27 16:23:35 +01:00

fishe's failure to resolve crux.ster.zone when installing contrib/x264 prompted me to dig deeper into this port. x264 is listed as a hard dependency for pipewire and gst-plugins-{bad,ugly} (among others). But pipewire and the gst-plugins all compile fine without x264 present. Even when built with x264 installed, pipewire and the gst-plugins do not report any linking to x264 when you run 'finddeps' on them.

Maybe x264 once satisfied a runtime dependency for pipewire and the gst-plugins by placing something in /usr/bin, but nowadays all it provides are shared objects and header files. In fact, the gst-plugins REQUIREMENTS blob says "GStreamer uses a large array of tools and libraries, most of which are optional. We have attempted to make sure that any code that depends on optional libraries doesn't get built unless you have those libraries."

A runtime dependency could conceivably arise indirectly through ffmpeg, which will link to x264 if found during its build. But ffmpeg itself only regards x264 as "Optional", so for a user with ffmpeg installed but not x264, running 'prt-get depinst pipewire' will not trigger a rebuild of ffmpeg to take advantage of this optional codec. Until the next ffmpeg version bump, such a user will have x264 libraries and headers sitting idle and unused, which basically undermines the case for listing x264 as a hard dependency of pipewire or gst-plugins-{bad,ugly}.

In the interest of "fluid Pkgfiles which can suit all use-cases" (FS#1576), I suggest to move x264 from "Depends on" to "Optional" in the pipewire and gst-plugins Pkgfiles. This move should mitigate some complaints about the unresolving crux.ster.zone hostname (although the easier fix for that issue is to use an upstream url for obtaining a source tarball, now that videolan.org offers such an API).

fishe's failure to resolve crux.ster.zone when installing contrib/x264 prompted me to dig deeper into this port. x264 is listed as a hard dependency for pipewire and gst-plugins-{bad,ugly} (among others). But pipewire and the gst-plugins all compile fine without x264 present. Even when built with x264 installed, pipewire and the gst-plugins do not report any linking to x264 when you run 'finddeps' on them. Maybe x264 once satisfied a runtime dependency for pipewire and the gst-plugins by placing something in /usr/bin, but nowadays all it provides are shared objects and header files. In fact, the gst-plugins *REQUIREMENTS* blob says "GStreamer uses a *large* array of tools and libraries, most of which are optional. We have attempted to make sure that any code that depends on optional libraries doesn't get built unless you have those libraries." A runtime dependency could conceivably arise indirectly through ffmpeg, which *will* link to x264 if found during its build. But ffmpeg itself only regards x264 as "Optional", so for a user with ffmpeg installed but not x264, running 'prt-get depinst pipewire' will not trigger a rebuild of ffmpeg to take advantage of this optional codec. Until the next ffmpeg version bump, such a user will have x264 libraries and headers sitting idle and unused, which basically undermines the case for listing x264 as a hard dependency of pipewire or gst-plugins-{bad,ugly}. In the interest of "fluid Pkgfiles which can suit all use-cases" (FS#1576), I suggest to move x264 from "Depends on" to "Optional" in the pipewire and gst-plugins Pkgfiles. This move should mitigate some complaints about the unresolving crux.ster.zone hostname (although the easier fix for that issue is to use an upstream url for obtaining a source tarball, now that videolan.org offers such an API).

farkuhar commented

2023-01-27 19:57:14 +01:00

The relevant part of the IRC discussion with fishe, for reference: https://libera.irclog.whitequark.org/crux/2023-01-27

Unlike contrib/smpeg which was also pointing to crux.ster.zone for downloading sources, our x264 port is lagging many soversions behind the latest upstream stable release. In case it was a deliberate choice to "freeze" x264 at soversion 148, I hesitated to commit a breaking change bumping the soversion up to 164. If the maintainers of handbrake and obs-studio do some testing and confirm that bumping x264 will not be a problem, then the easier fix mentioned above (changing the source url to videolan.org) can be deployed.

The relevant part of the IRC discussion with fishe, for reference: https://libera.irclog.whitequark.org/crux/2023-01-27 Unlike contrib/smpeg which was also pointing to crux.ster.zone for downloading sources, our x264 port is lagging many soversions behind the latest upstream stable release. In case it was a deliberate choice to "freeze" x264 at soversion 148, I hesitated to commit a breaking change bumping the soversion up to 164. If the maintainers of handbrake and obs-studio do some testing and confirm that bumping x264 will not be a problem, then the easier fix mentioned above (changing the source url to videolan.org) can be deployed.

tb commented

2023-01-28 00:47:25 +01:00

unresolving crux.ster.zone hostname

easiest fix would be for Danny to fix this and maintain his ports, IMO.

Anyhow, I pushed a few changes which should resolve your ticket.

> unresolving crux.ster.zone hostname easiest fix would be for Danny to fix this and maintain his ports, IMO. Anyhow, I pushed a few changes which should resolve your ticket.

farkuhar closed this issue

2023-01-28 01:37:14 +01:00

Sign in to join this conversation.