wget: needs libmetalink and gpgme dependencies (or drop --with-metalink)

[RJVB (René Bertin)]

It's all in the title. Port:wget is configured with --with-metalink but does not require port:libmetalink and port:gpgme (which is an additional requirement for this feature).

I can see how support for this feature could be useful but right now it is available only to users who build the port from source and happen to have the aforementioned dependencies installed.

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

[mf2k (Frank Schima)]

I see those hidden dependencies plus a few more:

Determining dependencies for:
/opt/local/bin/wget
depends_lib-append  port:gettext \
                    port:gnutls \
                    port:gpgme \
                    port:libassuan \
                    port:libgpg-error \
                    port:libiconv \
                    port:libidn2 \
                    port:libmetalink \
                    port:libpsl \
                    port:libunistring \
                    port:nettle \
                    port:pcre2 \
                    port:zlib

[RJVB (René Bertin)]

Those are all direct dependencies? I know the libgpg-error is a dependency of port:gpgme for instance, does wget depend on (use) it directly?

[mf2k (Frank Schima)]

Yes. My utility script parses the output of "otool -L" for the given input file and looks up all of the Macports dependencies that provide them.

[RJVB (René Bertin)]

That's nice but no guarantee that all dependencies found are indeed direct dependencies, or even required (used) dependencies. The link editor simply adds references to all shared libraries you tell it to include, and there are probably a few (or more) that are private dependencies of other dependencies. That's especially true in my experience when pkgconfig is used, which doesn't bother with subtleties like "on Mac you don't need to include the libraries this requested library depends on" (generally you do need them on Linux).

Case in point: you found libassuan as a dependency, but the fgrep -i assuan -R `port work wget` doesn't give a single hit.

FWIW, I prefer to keep depspec lists as short as possible with my own ports. If I depend on port:A which depends on port:B (and port:C) then I prefer to let port:A take care of getting its dependencies on B and C right. So rather than looking at what is actually linked to a port's binaries I look first and foremost at what configure or cmake tell me (easier with the former than with the latter). Of course, as a user I'm sometimes annoyed when I find out that some port with seemingly few dependencies actually needs a whole lot more, but what can you do :)

[kencu (Ken)]

Replying to RJVB:

FWIW, I prefer to keep depspec lists as short as possible with my own ports. If I depend on port:A which depends on port:B (and port:C) then I prefer to let port:A take care of getting its dependencies on B and C right.

Although it's tempting to have a huge tree of deps in the top port sometimes, it is senseless as you can't possibly keep with the changing landscape below you. So I completely agree with you.

[ryandesign (Ryan Carsten Schmidt)]

I seem to have missed this ticket.

Replying to 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 added by Jan six years ago. 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 ​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 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.

[ryandesign (Ryan Carsten Schmidt)]

In d66b4ca4ed0e783790c2a97aa58208f2b2723133/macports-ports (master):

wget: Update to 1.24.5; enable metalink, libproxy, xattr

Closes: #57794