[MacPorts] #69601: Installing recent versions of yq or wget installs libnetpbm which has a full X11/UI list of dependencies

[MacPorts]

#69601: Installing recent versions of yq or wget installs libnetpbm which has a
full X11/UI list of dependencies
----------------------------+------------------------
  Reporter:  tux-o-matic    |      Owner:  ryandesign
      Type:  defect         |     Status:  assigned
  Priority:  Normal         |  Milestone:
 Component:  ports          |    Version:
Resolution:                 |   Keywords:
      Port:  wget yq groff  |
----------------------------+------------------------

Comment (by ryandesign):

 Replying to [comment:13 lcvisser]:
 > Aside from the X11 dependencies I also see `libusb`,

 The first path to get to the libusb dependency from wget is that wget
 depends on gpgme which depends on gnupg2 which depends on libusb-compat
 which depends on libusb. I have not attempted to investigate whether all
 of those dependencies are actually used for anything useful. There may be
 more paths to a libusb dependency; `port rdeps` only shows the first one,
 unless the `--full` flag is used, which I never do because in my opinion
 it produces an unusably large volume of output.

 > 6 versions of `docbook-xml`,

 wget depends on libproxy which depends on vala which depends on docbook-
 xml which depends on the several versions of docbook-xml. Possibly, vala
 could be changed to depend on the specific version of docbook-xml that it
 requires, but I don't think that will result in a large disk space or time
 savings.

 > a ton of Python and Perl packages (while wget is written in C).

 Many of the perl dependencies come from git. wget -> libproxy -> vala ->
 graphviz -> gd2 -> libheif -> aom -> git.

 aom's git dependency is questioned in #66061.

 git used to be written in perl and thus required various perl modules but
 over time most of its functionality has been rewritten in C. You can opt
 out of the remaining perl functionality of the git port by installing it
 while deselecting the perl5_34 variant. I've started doing that on the
 MacPorts buildbot worker machines as I too was annoyed by having to
 install a bunch of perl modules, and then wrangle them when the default
 version of perl in MacPorts changed. It's worth investigating, in a
 separate ticket, if git's remaining perl functionality could be moved to a
 separate port or subport.

 Various ports in the dependency chain have dependencies on python modules.
 For example, meson is a build system written in python. wget -> libproxy
 -> vala -> glib2 -> meson.

 vala is a programming language. libproxy depends on vala so that it can
 provide language bindings that can be used to access libproxy from vala
 programs. It's worth investigating, in another ticket, if those language
 bindings could be in a separate port or subport.

 > it would be nice if there was a way to "opt-out" of them, e.g. via a
 variant.

 You have to be careful with moving functionality to variants because ports
 can't depend on variants of other ports (see #126) (other than by using
 the active_variants 1.1 portgroup, which requires manual user intervention
 and thus cannot work on the buildbot machines). Ports must therefore
 include all functionality that any other port might depend on. Where
 possible, optional functionality that only some users or other ports might
 need should be moved to subports. However, some build systems make this
 difficult or impossible.

 > I'm in a non-standard situation (corporate machine, no administrator
 rights, illegal group names with spaces, etc.) and build everything from
 source, so a lot of the problems I'm seeing are not MacPorts fault. I'm
 therefore hesitant to file a bug reports, unless I'm absolutely sure it's
 not due to my edge case configuration.

 Non-root MacPorts installations are supposed to be supported, though
 because they're not the default problems do creep in from time to time,
 which we do want to know about. Illegal group names with spaces are
 annoying but we have made changes to MacPorts in the past to accommodate
 them so I would not be opposed to seeing bug reports about such problems
 so they can be fixed. And often, by building from source you might simply
 be the first to run into a problem that others haven't seen yet because
 they received a binary we built before some problem existed, so those
 reports are valuable as well.

 > I'm not trying to be a smart ass. I've been using macports since my
 first Mac (Snow Leopard) and 99/100 times it works flawlessly. I'm aware
 that I'm in an unusual configuration which makes my life a bit harder than
 most users, but I'm hoping to see if I can contribute back for the few
 others (e.g. #69650) that are facing similar problems.

 No worries; we are happy to have bug reports and especially fixes.

 #69650, as far as I could tell, is specific to that user's system; it is
 not a general problem with non-root installations, for example, since I
 couldn't reproduce the problem.

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