[MacPorts] #57794: wget: needs libmetalink and gpgme dependencies (or drop --with-metalink) (was: port:wget needs depspecs for metalink and gpgme (or drop --with-metalink))

[MacPorts]

#57794: wget: needs libmetalink and gpgme dependencies (or drop --with-metalink)
---------------------+------------------------
  Reporter:  RJVB    |      Owner:  ryandesign
      Type:  defect  |     Status:  accepted
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:  wget    |
---------------------+------------------------
Changes (by ryandesign):

 * status:  assigned => accepted
 * cc: janstary (added)


Comment:

 I seem to have missed this ticket.

 Replying to [ticket:57794 RJVB]:
 > Port:wget is configured with `--with-metalink` but does not require
 `port:libmetalink` and `port:gpgme` (which is an additional requirement
 for this feature).

 > PS: why the `--disable-xattr` and (to a lesser extent) `--disable-rpath`
 configure options?

 Looking at `git blame`, all three flags were
 [changeset:126f8d18bf1c975c4f1dd32430c324bf770c3e4d/macports-ports added
 by Jan] six years ago. [comment:ticket:56076:6 As I said in another
 ticket], Jan's intention was not to enable or disable anything; it was to
 make explicit what the configure script was already choosing to do before,
 but a few mistakes were made, such as the unintentional disabling of
 digest authentication which had to be re-enabled again. Looks like the
 attempted enabling of metalink without also adding the libmetalink and
 gpgme dependencies is another so I'll fix that.

 I don't see a reason to add libassuan or libgpg-error dependencies. wget
 does not link with them. They are both dependencies of gpgme; libgpgme
 links with them. Back when this ticket was filed five years ago, gpgme had
 a bug where its pkg-config file stated that users of gpgme needed to link
 with libassuan and libgpg-error directly. (We call this "overlinking.")
 That bug was
 [https://github.com/gpg/gpgme/commit/4583ab77e5af3f0da5b307a169d07b58dddf652f
 fixed in gpgme] in 2021. So it's not about keeping the dependency list as
 short as possible; it's about specifying those libraries that the port
 links with directly, and ensuring that the software is actually using the
 libraries that it links with directly.

 I also pointed out in [comment:ticket:56076:6 that comment] that disabling
 of xattr support was a change. Looks like xattr support doesn't require
 any additional libraries. I don't know why we'd want to disable it so I'll
 turn it back on.

 As for rpath, I really don't know. I know that dyld in macOS gained the
 ability to work with libraries whose install names begin with `@rpath` in
 Mac OS X 10.5 and that an executable or other library that wants to use
 such a library needs to have an `LC_RPATH` attribute that specifies what
 `@rpath` should be replaced with to actually find the library. I don't
 know whether `--enable-rpath` is intended to build a library with an
 `@rpath` install name, to add the `LC_RPATH` attribute to a library or
 executable, both, or neither. Since macOS didn't have rpath support prior
 to Mac OS X 10.5 and got along fine without it, I tend not to understand
 why we would ever want to use it. Indeed, at times, we've had ports that
 decided to build their libraries with `@rpath` and it caused problems and
 they had to be changed to not do that; #61735 was an example of that. wget
 doesn't install any libraries, and the executable that it installs is
 linked with libraries installed by MacPorts which don't use `@rpath`, so I
 can't see anything in the wget port that would need rpath. If I remove
 `--disable-rpath` from the Portfile, then I find no case-insensitive
 matches for `rpath` in the build log, so I don't think this option is
 doing anything for us at all. So I don't have a strong opinion one way or
 the other as to whether this flag should stay or go.

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