[Exherbo-dev] [RFC] || ( ) dependencies and virtuals

Johannes Nixdorf mixi at shadowice.org
Wed Jan 1 22:03:56 UTC 2014


On Mon, Dec 30, 2013 at 10:55:29PM +0100, Quentin Glidic wrote:
> The ffmpeg vs. libav case is a bit more tricky. I will need the
> answer to one question to decide here: can you *always*
> runtime-switch between libav and ffmpeg? IOW, are some packages
> using build-time #ifs to use them?

They aren't compatible enough for that. This is from mpv's source code
(audio/filter/af_lavfi.c):

// FFmpeg and Libav have slightly different APIs, just enough to cause us
// unnecessary pain. <Expletive deleted.>
#if IS_LIBAV_FORK
#define graph_parse(graph, filters, inputs, outputs, log_ctx) \
    avfilter_graph_parse(graph, filters, inputs, outputs, log_ctx)
#else
#define graph_parse(graph, filters, inputs, outputs, log_ctx) \
    avfilter_graph_parse(graph, filters, &(inputs), &(outputs), log_ctx)
#endif

> If we *can* runtime-switch, a virtual is good here too.
> If we *cannot*, here are two and a half solutions:
> 1. a slot-based virtual. With a := slot dependency, that would force
> people to rebuild packages if they change from libav to ffmpeg

1. Packages are depending on specific, different versions of libav and
   ffmpeg. I don't see how we could do this with this virtual.
2. I don't see how the user could choose between the slots except mask
   the one with the higher version, which seems weird.

> 2. use [ffmpeg] and [libav] on each package, two variants here:
> a. make them mutually exclusive (but this is not
> DEFAULT_SRC_CONFIGURE_*-friendly, unless we add something to handle
> that choose-between -two-implementations case, which is quite
> common)
> b. make [libav] prefer libav over ffmpeg, while [ffmpeg] is always
> “use that feature” (which may confuse people for packages
> non-libav-aware that will lead to a blocker)

I'd go for one of those solutions.




More information about the Exherbo-dev mailing list