[MacPorts] #57150: Why graphical libraries as dependencies to console client?

[MacPorts]

#57150: Why graphical libraries as dependencies to console client?
-----------------------+------------------------
  Reporter:  Behinder  |      Owner:  ryandesign
      Type:  defect    |     Status:  assigned
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:
Resolution:            |   Keywords:
      Port:  pianobar  |
-----------------------+------------------------

Comment (by ryandesign):

 I understand your frustration and your initial impression that a simple
 command-line program like pianobar shouldn't have this many dependencies,
 or dependencies on software that performs functions that don't appear to
 be required.

 Pianobar's direct library dependencies (see `port deps pianobar`) are
 curl, ffmpeg, libao, libgcrypt, and json-c (and libpiano, pianobar's own
 library)—pianobar uses functions from those libraries directly—but each of
 those has additional dependencies, and so on.

 There are different ways one can approach installing a program like
 pianobar. If you care only about pianobar, then you would probably install
 the minimum of dependencies needed to run pianobar, and where those
 dependencies have optional features, you would enable only those features
 that pianobar would use.

 That's not the approach MacPorts takes, because we have to care about all
 of the software we offer, not just pianobar. And where a program or
 library offers optional features, we err on the side of enabling more
 features, even if not all users or programs or libraries will need them,
 for the benefit of those that do.

 For example, curl has optional support for internationalized domain names.
 Pianobar doesn't need this, but a user using curl might, so we enable IDN
 support; this causes a few additional libraries to be installed.

 As another example, ffmpeg is an audio/video conversion and download
 library, which pianobar uses to get the audio data from Pandora. Pianobar
 doesn't need ffmpeg's video conversion functionality, but a user or
 another port the user installs might, so we enable it, hence the video
 codecs and their dependencies. ffmpeg also has support for SVG files,
 which we enable, via a dependency on librsvg. librsvg has many
 dependencies of its own, including on the pango text library and the cairo
 graphics library, both of which have optional X11 support which we enable
 by default, hence the X11 dependencies. cairo depends on fontconfig, which
 depends on ossp-uuid, which has optional perl bindings which we enable by
 default, hence the dependency on perl.

 I hope this clarifies why the dependencies are there. The upshot is that
 even if you don't need all of this functionality for pianobar, it's there
 if you should need it for other ports you install. I see that curl and its
 dependencies weren't in your list of dependencies above, presumably
 because they were already installed for you when you previously requested
 them or another port that uses them, so you can see that the more ports
 you install and manage with MacPorts, the more they can share their
 dependencies.

 A couple days ago I installed pianobar onto a computer with a fresh
 MacPorts installation and no ports installed. Despite the number of
 dependencies, it only took a few minutes, since we offer precompiled
 binaries for a large number of our ports. So hopefully installing all
 these dependencies will not be too inconvenient.

 In some cases, we offer variants for enabling or disabling functionality.
 Using `port variants ossp-uuid` you can see that it has a "perl5_26"
 variant which is on by default; you can disable it with `sudo port install
 ossp-uuid -perl5_26` to avoid the perl dependency. fontconfig doesn't need
 ossp-uuid's perl bindings, but other ports might, so doing this would
 break those other ports, were you to install them. And perl is a very
 popular scripting language, which many ports use either in their build
 systems or at runtime, so you will most likely encounter other situations
 where MacPorts will install perl for you; the same can be said for python.

 For ports that have optional X11 functionality, we usually put it in a
 variant called "x11" and enable it by default. Many of these ports have an
 alternative variant "quartz" for using macOS-native graphics instead of
 X11. If you wish to use this, you can add `+quartz` and `-x11` to
 /opt/local/etc/macports/variants.conf but if you do this it is recommended
 that you uninstall all ports and then reinstall the ones you want, so that
 all ports get built with this choice.

 Note that we only build binaries of each port for its default set of
 variants, so even though disabling a variant might remove some
 dependencies, it might take longer to build the port from source than it
 would have to download the binaries. Also, building a port from source
 could also pull in additional build dependencies. So if your goal in
 changing a port's variants is to shorten installation time, it might not
 actually do that.

 If you have other questions about how MacPorts works or why it does what
 it does, the [https://www.macports.org/contact.php#Lists macports-users
 mailing list] is a better place to ask those questions. The Trac issue
 tracker is for bug reports and feature requests.

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