[Slackbuilds-users] The future of the mpv SlackBuild

[Matteo Bernardini]

2017-11-09 17:22 GMT+01:00 Andreas Guldstrand <andreas.guldstrand at gmail.com>:
> Hi all,
>
> I'm the current maintainer of the mpv SlackBuild, and don't worry, I'm
> not about to give it up or anything like that. I am however looking
> for opinions on how to proceed in the future because of a rather
> drastic change in mpv's dependencies.
>
> What has happened is this: mpv has dropped its dependency on ffmpeg,
> and instead depend on a specific mpv fork of ffmpeg that they call
> 'ffmpeg-mpv'. The reasons they've done so are not really relevant for
> this list, so let's not dwell on those (for the curious, you can take
> a look through https://github.com/mpv-player/mpv/commit/83d44aca7dc7f46b8d3b64d441f5a8317a40e080
> ).
>
> The issue I'm facing is how to deal with this change once a new
> version is released. I'm currently considering three options for how
> to proceed:
>
> 1. Include the building of 'ffmpeg-mpv' inside the mpv SlackBuild and
> statically link it, since it's likely that only mpv will be relying on
> the 'ffmpeg-mpv' fork.
>
> 2. Make a new 'ffmpeg-mpv' SlackBuild and try to make sure it doesn't
> conflict with the regular ffmpeg SlackBuild.
>
> 3. Wait for other distributions to make patches for mpv available so
> it can play nice with the regular ffmpeg. I'd of course also take such
> patches from the SlackBuilds.org community should you be able to
> provide such things. There is no chance that I would make one on my
> own however.
>
> I'm personally favouring option 1, but would like input from the rest
> of the community.
>
> There are a few things that make me consider option 3 as my least
> favourite option. For instance the mpv folks are less likely to
> support a nonstandard build like that, and it makes us dependent on
> other distributions keeping up with changes to both ffmpeg and mpv.
>
> I am still considering it though since it will mean there is only one
> ffmpeg on SBo, so you only need to build it for the first program that
> depends on it, it won't cause conflicts, and all the options for
> ffmpeg are quite a chore to need to make sure they all work as they
> should.

IMHO I would go for the first option (looks the cleanest to me),
eventually moving to the second only if needed by something else.

Matteo