[Slackbuilds-users] The future of the mpv SlackBuild

[Andrzej Telszewski]

On 09/11/17 17:31, Matteo Bernardini wrote:
> 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.
> 

If possible, I wouldn't link statically, but install shared ffmpeg-mpv 
in lib dir specifically created and known for mpv. But, meh ;-)

Option (2) makes sense if both mpv and ffmpeg-mpv are kept and updated 
separately. So for example ffmpeg-mpv is at version 0.1 and mpv goes 
from 0.1 -> 0.2, then you only need to update mpv. Otherwise, use method 
(1) to keep house clean.

You can surely wait to see what others do (i.e. option 3). The more 
input, the better :-)

Thanks for the job!

-- 
Best regards,
Andrzej Telszewski