[Slackbuilds-users] The future of the mpv SlackBuild

[Andreas Guldstrand]

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.

Regards / Andreas Guldstrand