[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 lcvisser):

 Replying to [comment:12 ryandesign]:

 > I can't find any current MacPorts bug reports about py312-pluggy. Please
 file individual tickets for each port that fails to build so that it can
 be investigated and fixed.

 The problem is not in py312-pluggy itself but elsewhere; py312-pluggy just
 happened to be the first one to trip over it. I'm still trying to figure
 out what is going on exactly.

 > That's not an actionable suggestion. If you have specific knowledge of a
 dependency that is not needed somewhere, please file a bug report or pull
 request with appropriate evidence. It's certainly possible that a
 dependency used to be needed by some port but then it was updated to a new
 version that doesn't need it anymore and we didn't notice. Or a dependency
 could have been added erroneously. But for each dependency that you
 believe a port doesn't need, some investigation would have to happen by
 you or someone else to confirm it and take the appropriate action. For
 example, if a dependency is optional and we want to remove it, we
 additionally must ensure that it does not get used if it happens to be
 installed, otherwise builds are not [wiki:ReproducibleBuilds
 reproducible].

 Aside from the X11 dependencies I also see `libusb`, 6 versions of
 `docbook-xml`, a ton of Python and Perl packages (while wget is written in
 C). I suspect that a lot of these dependencies get pulled in for the build
 process, perhaps for documentation generation.  Perhaps "should not be
 there" is not the best wording from my side, but it would be nice if there
 was a way to "opt-out" of them, e.g. via a variant.

 > I'm sorry to hear that; that's obviously not the experience we want
 users to have. We can't fix problems we don't know about, so report each
 problem you find, presuming reports do not already exist for those
 problems.

 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.

 >
 > > I'd be very happy to spend that time in contributing to a solution
 (cutting down the dependency list) instead, but not sure where to start.
 Some pointers?
 >
 > Well Josh said:
 >
 > > Replying to [comment:1 jmroot]:
 > > > For wget the dependency comes in via gpgme: gnupg2 -> openldap ->
 (build-time dependency only) groff -> netpbm
 >
 > And I replied:
 >
 > Replying to [comment:4 ryandesign]:
 > > groff's netpbm dependency has been there
 [changeset:37fbab0efe1bd3435a92c643c77b690e7b1700e9/macports-ports for 13
 years] however
 [https://lists.gnu.org/archive/html/groff/2014-03/msg00125.html the
 developer of groff says] "With the distributed tarballs, there is *no*
 dependency on Netpbm!"
 >
 > I can remove the netpbm dependency, if it's truly not needed, however
 that still leaves ghostscript which also depend on X11 when its x11
 variant is selected, which it is by default.
 >
 > And I'm not convinced that netpbm is not needed. The groff Portfile says
 the reason the dependencies are there is because they are specified in
 groff's README, and indeed they are:
 >
 > > {{{
 > > Ghostscript is required for creation of PDF and (X)HTML output.
 > > Production of (X)HTML furthermore demands tools from the 'netpbm' and
 > > 'psutils' packages.
 > > }}}
 >
 > Perhaps a new discussion needs to be had with the developer of groff to
 get to the bottom of it. Is the README out of date? Or, if the README
 remains accurate, is it the case that we have no need for MacPorts groff
 to produce (X)HTML and we can therefore instruct it not to use netpbm or
 psutils? If you'd like to start that discussion with the developer, or if
 you find an existing discussion that answers the question, please provide
 a link to it here.


 Is it possible to use the `port` utility to systematically trace
 dependencies? I'd be interested to learn what the dependency tree looks
 like and if there are port variants that can cut down the tree a bit (seem
 like installing Ghostscript without the x11 variant would be a good
 start...)

 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.[https://trac.macports.org/ticket/69650]) that are facing similar
 problems.

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