Re: Options of dependencies

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

Frédéric Fauberteau <triaxx%NetBSD.org@localhost> writes:

> I am seeing for packaging ffx264 (https://ffx264.teambelgium.net/) and
> there is as requirement:
> - FFmpeg compiled with support for the following libraries:
> o    libx264
> o    libfdk-aac
> o    libopus
> o    libmp3lame
> o    libvorbis
> o    z library (zimg)
> For instance, fdk-aac is not in PKG_SUGGESTED_OPTIONS of ffmpegX.
>
> Is there a proper way to "enforce" options for a dependency? If
> ffmpegX is already installed without all wanted options, it should be
> rebuild with the correct ones...

No.  pkgsrc fundamentally has no notion of this, and really has no
notion of forcing a rebuild, just a build.  And the build will be with
the options as documented, not some other options.

So the paths forward (echoing what others have said) are:

  1) figure out how to make ffx264 cope with the default options of ffmpeg

  2) check and fail as leot@ has suggested

  3) see if it makes sense to change the default options for ffmpeg
  (obviously not during the freeze).  This is tricky, as options often
  pull in more dependencies and sometimes those don't build everywhere,
  or have licensing issues.

  In thinking about default options, we should realize that we are
  making choices for people that don't necessarily know what they should
  want (often because there is just so much software, and it's not
  reasonable to take the time to understand it).  This is some blend of
  useful and bloat, where bloat is measured relative to what's likely
  already present.

  In this case, fdk-aac has a non-free license, and it's incompatible
  with the ffmpeg license.  So if we were to enable libdfk-aac by
  default, we would not be able to distribute binary packages of ffmpeg.
  That's actually encoded in the options file, although the reasoning
  isn't quite right.  Perhaps, the fdk-aac package should be marked for
  not being distributed, but the tone of the license is that it's ok to
  distribute the code with the notion that people are supposed to obtain
  patent licenses separately.

So I think your options are 1 and 2.

> I seen nothing in this sense. For now, my option is a MESSAGE file
> that gives these requirement.

Please don't use MESSAGE.  (Really, ever.)  MESSAGE is supposed to be
shown to the user after the package is installed, when something special
has to be done, but can't have been done in the package.   MESSAGE files
typically tell people to read the documentation, or paraphrase things
they should have learned from reading the documentation.  With package
managers, they tend to scroll by.   So we should get rid of them all :-)