Re: address@hidden: 02/02: gnu: mpv: Update to 0.28.0.]

[Rutger Helling]

Hi Leo,

On Wed, 27 Dec 2017 18:20:01 -0500
Leo Famulari <address@hidden> wrote:

> On Wed, Dec 27, 2017 at 08:52:12PM +0100, Rutger Helling wrote:
> > Hi Leo,
> > 
> > You can find the new features at:
> > https://github.com/mpv-player/mpv/blob/master/RELEASE_NOTES
> > 
> > There are two reasons for me personally why I wanted to update:
> > 1. The mpv developers only support the latest release.
> > 2. The initial Vulkan support, which I've got working (x86_64 only
> > for now). I can't merge it yet until core-updates is merged though.
> > 
> > I agree having three ffmpeg versions is undesirable. However,
> > looking at the release notes ("This release needs recent FFmpeg
> > (newer than 3.4) due to major refactoring.") this is hopefully a
> > one-time thing.
> > 
> > When stable ffmpeg is updated we can get rid of the -git version.
> > mpv is the only one using the -git version and it's been very solid
> > for me, so I don't foresee problems there. Replacing address@hidden
> > entirely with this -git version seems too extreme a solution to me.
> > 
> > Hopefully that explains my rationale a bit!  
> 
> Okay, let's keep this mpv and FFmpeg. I'm always eager to update to
> the latest releases of C-language programs that handle untrusted
> input, and it sounds like the mpv team is moving on from mpv 0.27.0.
> 
> Personally I think it's bad practice for mpv to depend on some random
> commit of FFmpeg, but that is mpv's choice.
> 

I agree, it's an unfortunate situation that hopefully shouldn't take
too long.

> In the future, please send patches that introduce unreleased versions
> of widely used libraries like FFmpeg to guix-patches for review.
> 
> The packaging guidelines say, "We usually package only the latest
> version of a given free software project." [0]
> 

I'll send a patch in next time first, sorry about any inconvenience.
Hopefully this is a one-time situation though.

> I interpret "latest version" to mean the latest version released in
> the way that the upstream developers typically do their releases. For
> FFmpeg, this is a tarball.
> 
> Thank you very much for taking the time to explain your rationale!
> 
> [0]
> https://www.gnu.org/software/guix/manual/html_node/Version-Numbers.html

pgpjLzYBcrNrT.pgp
Description: OpenPGP digital signature