Date: Sat, 16 Jul 2022 18:07:20 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 265250] ports-mgmt/portmaster -F does not suppress build of depends (for sysutils/restic, for one) Message-ID: <bug-265250-7788-aDAYxtOQPA@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-265250-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-265250-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265250 Stefan E=C3=9Fer <se@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open --- Comment #1 from Stefan E=C3=9Fer <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+=3D ${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 fet= ch") 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 por= t. 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 wi= th that status. Feel free to submit a patch that disables the updating of "slightly" outdat= ed 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 ...) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-265250-7788-aDAYxtOQPA>