Thanks! We considered a wrapper script that adds --compat-options,
along with a module wrapper. The module wrapper is clearly a bad idea
(and there are packages that depend/recommend youtube-dl and then
import the python module), but I'm leaning against having a wrapper
script. As you mentioned, it would need a conflicts/provides, still
wouldn't provide the python module, and may be more of a hassle than
simply having an empty youtube-dl with a NEWS entry letting people know
about the change. I'm also very worried about silent bugs with
--compat-options that aren't caught because most yt-dlp developers end
up not using and testing it. That's specifically why I'm asking package
maintainers to test out yt-dlp to make sure it works as intended.
On Wed, Nov 16 2022 at 09:21:02 PM +0000, Barak A. Pearlmutter
<ba...@pearlmutter.net> wrote:
Can do, although patches would be welcome.
Here's a broader suggestion though. I can change the dependency to
"yt-dlp | youtube-dl", but how about if yt-dlp sets up an alternative
(using update-alternatives) for /usr/bin/youtube-dl to a little script
that tosses a "--compat-options" onto the front and trampolines to
yt-dlp. I suppose youtube-dl should have a final version uploaded that
also sets itself up with the same update-alternative thing (move the
actual executable to /usr/lib/youtube-dl/youtube-dl), and yt-dlp would
need to conflict with previous versions of youtube-dl, and should also
provide:youtube-dl. Anyway, the upshot would be a graceful transition.
And I'd put a version on the yt-dlp dependency of this particular
package. But in general user scripts which invoke youtube-dl (of which
there must be a gazillion; I myself have dozens scattered about) would
keep working.
What do you think?
