[Slackbuilds-users] The future of the mpv SlackBuild

[Doogster]

Have the mpv SlackBuild install ffmpeg-mpv into /usr/lib/mpv or
/usr/lib64/mpv. Then have it build mpv with -Wl,-rpath,/usr/lib/mpv or
-Wl,-rpath,/usr/lib64/mpv. Have both /usr/lib$LIBDIRSUFFIX/mpv and mpv
in the same package.

On Thu, Nov 9, 2017 at 9:51 AM, Andrzej Telszewski
<atelszewski at gmail.com> wrote:
> 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
>
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
>