Re: CVS commit: pkgsrc/net/yt-dlp

[Greg Troxel <gdt%lexort.com@localhost>]

Leonardo Taccari <leot%NetBSD.org@localhost> writes:

> Greg Troxel writes:
>> [...]
>> Modified Files:
>>      pkgsrc/net/yt-dlp: DESCR
>> Removed Files:
>>      pkgsrc/net/yt-dlp: MESSAGE
>>
>> Log Message:
>> net/yt-dlp: Move MESSAGE to DESCR
>>
>> Hints about programs that work with yt-dlp don't meet the documented
>> reasons for MESSAGE.  Really, they are pointing out that programs that
>> should perhaps be dependencies are not, which fits with DESCR's
>> mission to describe what is (and is not) in the package.
>>
>> (Probably there should be options to depend on these other packages,
>> and creating an options.mk would clarify why they are needed and in
>> which combinations, but I don't understand the details.)
>> [...]
>
> I disagree with that and I don't think that DESCR should be used for
> that.

We had a lengthy discussion about this, came to rough consensus, and
documented the conclusion in the pkgsrc guide.

  MESSAGE

      This file is displayed after installation of the package. While this was
      used often in the past, it has two problems: the display will be missed if
      many packages are installed at once, and the person installing the package
      and the one using or configuring it may be different. It should therefore
      be used only in exceptional circumstances where lasting negative
      consequences would result from someone not reading it.

      MESSAGE should not be used for:

        o exhortations to read the documentation

        o reminders to install rc.d files and set variables

        o anything that should be explained in the installation/configuration
          documentation that should come with the package

      If the documentation provided by upstream needs enhancing, create e.g.
      files/README.pkgsrc and install it in the package's documentation
      directory.

Suggestions to install additional packages are exactly something "that
should be explained in the installation/configuration documentation that
should come with the package".

>From that, it follows solidly that this content in MESSAGE is not ok.

> I think that DESCR should be a *description of the package* and should
> not contains such "please also install ..." or similar instructions.

It is sort of "please also install" but I see it as "yt-dlp expects
these packages to be installed, but for unclear reasons this package
does not depend on them, and thus *what this package contains* is
different from reasonable expectations".  Which is describing what is in
the package, by avoiding giving the wrong impression that programs used
by yt-dlp are indirectly included.

> I think that's exactly what MESSAGE is for.

The rough consensus was that MESSAGE is shouty and not compatible with
pkgin or anything other than building one package at a time.

I see almost MESSAGE files as abuse of a critical-notice mechanism to
stick random documentation someplace other than where documentation
belongs.  That would be the man page, or something in
/usr/pkg/share/doc/yt-dlp.  When encountering them I essentially never
find that they are ok -- it is more that it is significant work to fold
them into documentation where they belong.

I see now that there is a yt-dlp man page, and it says that ffmpeg is
strongly recommended.  With that, there's no need to describe
specifically what's missing and what the user might want to install.  I
just removed the specific advice from DESCR, noting only that the
package does not depend on things that upstream says are strongly
recommended.

> More in general...
> I also do not get what's wrong with MESSAGEs... I understand that it
> has a not good UX because if someone install a lot of packages they can
> miss a MESSAGE. However, I think that's fixable... we even had/have a
> possible project that could be suitable for GSoC (but I've dropped the
> GSoC tag because last year it started a bikeshed that was likely not
> suitable to be taken by a new contributor/student).

What's wrong is that it's a kitchen sink place for random info that
belongs in documentation and for various (not valid) reasons isn't in
documentation, and that instead of a way to look at documentation it's
shouty at people installing packages.  It presumes that the person
installing is the person using the package.  It presumes that packages
are installed one at a time.  More importantly, we had this discussion
and reached rough consensus.  We almost had consensus to deprecate it
entirely, but a few people thought that some packages might qualify
under "lasting negative consequences" (meaning data loss if you don't
pay attention).  Even though no such packages were identified.  Just the
concept that they might exist.  And of course, understanding that if
they did exist, they'd be buggy (albeit likely upstream buggy).

> My muscle memory sometimes still checks `pkg_info -D <package>` if I
> need to check something about that package.

Do you read man pages and look in /usr/pkg/share/doc/pkg/*?  I realize
everybody has different habits, but MESSAGE was never meant to be the
main documentation, or the entry point to documentatin.  It has always
been at least somewhat unusual for a package to have a MESSAGE.  We used
to have over 1000 and we're down to 629.

Stepping back and thinking about yt-dlp, the real question is: why does
this not depend on ffmpeg and a javascript engine?  As I see it
(fuzzily), our install, by upstream standards, is defective, because
things that are strongly recommended aren't depended on.  Once that's
fixed, the question of how to warn people is no longer important.

This is in general my feeling about MESSAGE -- that almost everything in
it is a symptom that the package is not as it should be (or that
upstream is not as it should be).

Depending on ffmpeg would force choosing a version, and figuring out how
to make the installed yt-dlp call that version.  Looking at the sources
quickly, it looks for ffmpeg and ffprobe, and won't find our versioned
names.  So it seems that just installing ffmpeg isn't enough to make
yt-dlp use it.

My guess at the right path forward:

  Add options.mk

  Add default-on option ffmpeg that depends on the recommended version.
  Probably 8, maybe 7.

  Patch the sources to call ffmpeg8, not ffmpeg, so it's found.

  Add default-on option to do the right thing with the javascript stuff.


Or maybe you don't think these need to be options, and should just be
straight dependencies.

Would you object to just adding a ffmpeg8 dependency?   Do people want
to use yt-dlp without ffmpeg in significant number?