[Bug 265250] ports-mgmt/portmaster -F does not suppress build of depends (for sysutils/restic, for one)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265250

Stefan Eßer <se@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Open

--- Comment #1 from Stefan Eßer <se@FreeBSD.org> ---
(In reply to Matthias Andree from comment #0)

What do you suggest to do if a port cannot be fetched without some programs
being present?

$ make -C 7usr/ports/sysutils/restic -V FETCH_DEPENDS
/usr/local/bin/go118:lang/go118  ca_root_nss>0:security/ca_root_nss

In this particular case the use of GO_MODULE requires a matching go binary to
exist:

.    if defined(GO_MODULE)
[...]
FETCH_DEPENDS+= ${GO_CMD}:${GO_PORT} \
                ca_root_nss>0:security/ca_root_nss
[...]
.  endif

Please explain how "make fetch" can be executed in this case if no matching go
binary can be found?

And since "portmaster -F" executes "make checksum" (which implies "make fetch")
this is exactly the same behavior as you'd get by directly executing "make
fetch" for this port.

One difference is that portmaster wants to update outdated ports before they
are used as a dependency, and thus might want to update go118 after a
PORTREVISON bump, while a plain "make fetch" ignores the outdated go118 port.

But since there is no algorithmic method that could distinguish the case of a
required port update from a cosmetic one, portmaster has to assume that an
update is required.

I'm considering this a "works as designed" case and want to close the PR with
that status.

Feel free to submit a patch that disables the updating of "slightly" outdated
FETCH_DEPENDS, but not the installation of missing ones or upgrade of stale
fetch dependencies that are installed but do not provide the required level of
run time support for the often complex fetch operation of a port that needs
FETCH_DEPENDS.
(And no, a solution that is only tested and working for the special case of
GO_MODULE does not suffice ...)

-- 
You are receiving this mail because:
You are the assignee for the bug.