[MacPorts] #66424: FFmpeg{-upstream} Portfiles seems to have an inordinate amount of dependencies? Is there a way to improve upon this?

[MacPorts]

#66424: FFmpeg{-upstream} Portfiles seems to have an inordinate amount of
dependencies? Is there a way to improve upon this?
--------------------------+--------------------
  Reporter:  artkiver     |      Owner:  (none)
      Type:  enhancement  |     Status:  new
  Priority:  Low          |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:  ffmpeg       |
--------------------------+--------------------

Comment (by artkiver):

 Replying to [comment:6 mascguy]:
 > Replying to [comment:3 artkiver]:
 > > To be honest, I am not entirely sure why there are three separate
 FFmpeg ports especially since two of them are both an older version?
 >
 > `ffmpeg-upstream` tracks the latest release (currently 5.x). While
 `ffmpeg-devel` is used to validate pending changes to `ffmpeg`, before
 rolling out to everyone.
 >
 > So yes, this is intentional.

 Thank you for that clarification. I guess the delineation still makes zero
 sense to me, given that ffmpeg-devel is still public; and "rolling out to
 everyone" seems as if it would be a nomenclature perhaps more suitable for
 private branches and repositories than something within the MacPorts
 system?

 At least in the instance of libressl as contrasted with libressl-devel,
 that appears to be related to the upstream project tagging some releases
 as Development and some releases as Stable; so it's a nomenclature from
 the upstream project, rather than an artifact of MacPorts' maintainer
 methodologies. Nonetheless, it's your bailiwick. I already offered one
 possible alternative.

 I do not think a preference for minimalism and adherence to upstream
 defaults is an unusual preference, but I am not here to pick a battle.

 > > I suppose a ffmpeg-minimal is another possibility, but creating a 4th
 Portfile, when it seems as if it might be better to clean up the existing
 3 separate, yet very closely related, ports might make more sense?
 >
 > We've considered various options, including adding more variants. But
 that quickly becomes a testing nightmare, due to the sheer number of
 combinations.
 >
 > In short, there's simply no way to please everyone. Even today, there
 are open enhancement requests to add still more functionality.
 >
 > So while you may prefer something simplified, that's at odds with
 others.

-- 
Ticket URL: <https://trac.macports.org/ticket/66424#comment:8>
MacPorts <https://www.macports.org/>
Ports system for macOS