GNU bug report logs - #61117
Update svtplay-dl to 4.18

Previous Next

To reply to this bug, email your comments to 61117 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jessica Tallon <tsyesika <at> tsyesika.se>
To: guix-patches <at> gnu.org
Subject: Update svtplay-dl to 4.18
Date: Sat, 28 Jan 2023 12:29:03 +0100

[Message part 1 (text/plain, inline)]

Hello,

I've attached a patch to upgrade svtplay-dl from 4.17 to 4.18. I've also moved 
ffmpeg form inputs to propagated-inputs as it's needed while the program is 
running to merge two files, not while building.

Thanks,
Jessica.

[0001-gnu-packages-video.scm-svtplay-dl-update-to-4.18.patch (text/x-patch, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Jessica Tallon <tsyesika <at> tsyesika.se>
Cc: 61117 <at> debbugs.gnu.org, guix-patches <at> gnu.org
Subject: Re: [bug#61117] Update svtplay-dl to 4.18
Date: Sat, 28 Jan 2023 13:33:44 +0100

[Message part 1 (text/plain, inline)]

Jessica,

Jessica Tallon 写道：
> I've attached a patch to upgrade svtplay-dl from 4.17 to 4.18.

Thanks!

> I've also moved ffmpeg form inputs to propagated-inputs

Please avoid propagation whenever possible; it breaks all kinds of 
nice things.

Propagating A from B means that Guix will effectively ‘install’ A 
alongside B when the user installs only B.  Or how classical 
package managers bluntly handle ‘dependencies’.  Not good!

Here's what I'd do instead [untested]:

   (arguments
    (list #:phases
          #~(modify-phases %standard-phases
              (add-after 'wrap 'wrap-harder
                (lambda* (#:key inputs outputs 
                #:allow-other-keys)
                  (wrap-script (string-append (assoc-ref outputs 
                  "out")
                                              "/bin/svtplay-dl")
                    `("PATH" ":" prefix
                      (,(dirname (search-input-file inputs
                                                    "bin/ffmpeg"))))))))))
   (native-inputs (list guile-3.0))    ; for wrap-script

> it's needed while the program is 
> running to merge two files, not while building.

So 4.17 did not need or use ffmpeg this way?

Otherwise, put each unrelated changes into a separate commit: one 
to improve the ffmpeg situation, and one to update svtplay-dl. 
You can send multiple related commits as one patch series to one 
bug number, though.

Kind regards,

T G-R

[signature.asc (application/pgp-signature, inline)]

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: Jessica Tallon <tsyesika <at> tsyesika.se>, 61117 <at> debbugs.gnu.org,
 guix-patches <at> gnu.org
Subject: Re: [bug#61117] Update svtplay-dl to 4.18
Date: Sat, 28 Jan 2023 13:58:53 +0100

[Message part 1 (text/plain, inline)]

Tobias Geerinckx-Rice via Guix-patches via 写道：
>                 (lambda* (#:key inputs outputs
>                 #:allow-other-keys)           ^

Dunno why mu4e added a hard newline here.  There shouldn't be one.

Kind regards,

T G-R

[signature.asc (application/pgp-signature, inline)]

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: Jessica Tallon <tsyesika <at> tsyesika.se>, 61117 <at> debbugs.gnu.org,
 guix-patches <at> gnu.org
Subject: Re: [bug#61117] Update svtplay-dl to 4.18
Date: Sat, 28 Jan 2023 14:02:39 +0100

[Message part 1 (text/plain, inline)]

Tobias Geerinckx-Rice via Guix-patches via 写道：
>                   (wrap-script (string-append (assoc-ref outputs
>                   "out") 
>                   ^

And here.  All the others are good.  Sorry for the mess.

Kind regards,

T G-R

[signature.asc (application/pgp-signature, inline)]

Message #28 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jessica Tallon <tsyesika <at> tsyesika.se>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 61117 <at> debbugs.gnu.org, guix-patches <at> gnu.org
Subject: Re: [bug#61117] Update svtplay-dl to 4.18
Date: Sun, 05 Mar 2023 11:05:28 +0100

[Message part 1 (text/plain, inline)]

Hello,

Sorry for the long delay on addressing this feedback.

Tobias Geerinckx-Rice <me <at> tobias.gr> writes:

> [[PGP Signed Part:Undecided]]
> Jessica,
>
> Please avoid propagation whenever possible; it breaks all kinds of
> nice things.
>
> Propagating A from B means that Guix will effectively ‘install’ A
> alongside B when the user installs only B.  Or how classical package
> managers bluntly handle ‘dependencies’.  Not good!
>

Thanks for the tip, I've included a patch which does it this way.

>
>> it's needed while the program is running to merge two files, not
>> while building.
>
> So 4.17 did not need or use ffmpeg this way?
>
> Otherwise, put each unrelated changes into a separate commit: one to
> improve the ffmpeg situation, and one to update svtplay-dl. You can
> send multiple related commits as one patch series to one bug number,
> though.

4.17 did indeed need ffmpeg, I've included two patches one which
resolves the ffmpeg issue and the other which updates it to 4.18.

Thanks,
Jessica.

[0000-cover-letter.patch (text/x-patch, attachment)]

[0001-gnu-fix-svtplay-dl-wrapping-to-use-ffmpeg.patch (text/x-patch, attachment)]

[0002-gnu-svtplay-dl-update-to-4.18.patch (text/x-patch, attachment)]

Message #34 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jessica Tallon <tsyesika <at> tsyesika.se>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 61117 <at> debbugs.gnu.org, guix-patches <at> gnu.org
Subject: Re: [bug#61117] Update svtplay-dl to 4.18
Date: Sun, 5 Mar 2023 11:39:10 +0100

[Message part 1 (text/plain, inline)]

Hello,

Sorry for the long delay on addressing this feedback.

Tobias Geerinckx-Rice <me <at> tobias.gr> writes:
> Jessica,
>
> Please avoid propagation whenever possible; it breaks all kinds of
> nice things.
>
> Propagating A from B means that Guix will effectively ‘install’ A
> alongside B when the user installs only B.  Or how classical package
> managers bluntly handle ‘dependencies’.  Not good!
>

Thanks for the tip, I've included a patch which does it this way.

>
>> it's needed while the program is running to merge two files, not
>> while building.
>
> So 4.17 did not need or use ffmpeg this way?
>
> Otherwise, put each unrelated changes into a separate commit: one to
> improve the ffmpeg situation, and one to update svtplay-dl. You can
> send multiple related commits as one patch series to one bug number,
> though.

4.17 did indeed need ffmpeg, I've included two patches one which
resolves the ffmpeg issue and the other which updates it to 4.18.

Thanks,
Jessica.

[0000-cover-letter.patch (text/x-patch, attachment)]

[0001-gnu-fix-svtplay-dl-wrapping-to-use-ffmpeg.patch (text/x-patch, attachment)]

[0002-gnu-svtplay-dl-update-to-4.18.patch (text/x-patch, attachment)]

Message #40 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Tobias Geerinckx-Rice via Guix-patches via <guix-patches <at> gnu.org>
Cc: Jessica Tallon <tsyesika <at> tsyesika.se>, 61117 <at> debbugs.gnu.org
Subject: Re: [bug#61117] Update svtplay-dl to 4.18
Date: Sun, 5 Mar 2023 15:13:36 -0500

Thanks again for working on this package!

On Sat, Jan 28, 2023 at 01:33:44PM +0100, Tobias Geerinckx-Rice via Guix-patches via wrote:
> > I've also moved ffmpeg form inputs to propagated-inputs
> 
> Please avoid propagation whenever possible; it breaks all kinds of nice
> things.

I'm here to express my weak preference for dynamically binding FFmpeg in
use cases like this one.

That means, I prefer if packages like svtplay-dl do not depend on FFmpeg
at all, but rather expect the user to install FFmpeg alongside them.

I prefer this because I use a custom FFmpeg professionally as a video
engineer, and it's easier to use it with Guix packages if the dependency
is resolved at run-time rather than at build-time.

I'd expect that many people like me also use a variety of custom FFmpeg
builds for different use cases.

Like I said, it's a weak preference. And I probably wouldn't use
svtplay-dl at work in the US, although I do use youtube-dl / yt-dlp. Let
me know what you think.

Message #46 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jessica Tallon <tsyesika <at> tsyesika.se>
To: Leo Famulari <leo <at> famulari.name>
Cc: 61117 <at> debbugs.gnu.org,
 Tobias Geerinckx-Rice via Guix-patches via <guix-patches <at> gnu.org>
Subject: Re: [bug#61117] Update svtplay-dl to 4.18
Date: Sun, 05 Mar 2023 21:15:14 +0100

Leo Famulari <leo <at> famulari.name> writes:

> Thanks again for working on this package!
>
> On Sat, Jan 28, 2023 at 01:33:44PM +0100, Tobias Geerinckx-Rice via Guix-patches via wrote:
>> > I've also moved ffmpeg form inputs to propagated-inputs
>> 
>> Please avoid propagation whenever possible; it breaks all kinds of nice
>> things.
>
> I'm here to express my weak preference for dynamically binding FFmpeg in
> use cases like this one.
>
> That means, I prefer if packages like svtplay-dl do not depend on FFmpeg
> at all, but rather expect the user to install FFmpeg alongside them.
>
> I prefer this because I use a custom FFmpeg professionally as a video
> engineer, and it's easier to use it with Guix packages if the dependency
> is resolved at run-time rather than at build-time.
>
> I'd expect that many people like me also use a variety of custom FFmpeg
> builds for different use cases.
>
> Like I said, it's a weak preference. And I probably wouldn't use
> svtplay-dl at work in the US, although I do use youtube-dl / yt-dlp. Let
> me know what you think.

Hello,

Thanks for sharing your experiance, especially as a professional video
engineer :)

I think I have a mild opinion for having it bring in ffmpeg, this is
mostly for three reasons:

- There isn't a good way to communicate to users that they might wish to
  pull in ffmpeg.
  
- svtplay-dl will download both audio and video parts and then realise
  it doesn't have ffmpeg and will give up producing a warning. This
  leaves it up to the user to fix, while a merging both files is a
  simple job it often has me searching through a manual as I'm not well
  versed in ffmpeg or similar.

- I like it when things work consistantly (if x version of svtplay-dl
  works a specific way on my machine, it should on another machine, not
  dependent on my profile)

My preference is mild though, let me know what you think!

Thanks,
Jessica.

Message #52 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Jessica Tallon <tsyesika <at> tsyesika.se>
Cc: 61117 <at> debbugs.gnu.org,
 Tobias Geerinckx-Rice via Guix-patches via <guix-patches <at> gnu.org>
Subject: Re: [bug#61117] Update svtplay-dl to 4.18
Date: Sun, 5 Mar 2023 15:58:27 -0500

On Sun, Mar 05, 2023 at 09:15:14PM +0100, Jessica Tallon wrote:
> I think I have a mild opinion for having it bring in ffmpeg, this is
> mostly for three reasons:
> 
> - There isn't a good way to communicate to users that they might wish to
>   pull in ffmpeg.
>   
> - svtplay-dl will download both audio and video parts and then realise
>   it doesn't have ffmpeg and will give up producing a warning. This
>   leaves it up to the user to fix, while a merging both files is a
>   simple job it often has me searching through a manual as I'm not well
>   versed in ffmpeg or similar.
> 
> - I like it when things work consistantly (if x version of svtplay-dl
>   works a specific way on my machine, it should on another machine, not
>   dependent on my profile)
> 
> My preference is mild though, let me know what you think!

I think you should go with your method!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.