Created attachment 191380 [details] Patch to portmaster to allow FETCH_ONLY without requiring "install" privelege During src-based system updates, it has been my practice to run `portmaster -aF` while "make buildworld" (& friends) run; usually, the timing is such that the distfiles are fetched by the time the installworld is done, and this makes a good use of resources. Then, after the reboot, I can run `portmaster -ad` without that process getting bogged down in waiting on receipt of files (well, mostly, anyway). However, I found that on a system where I (vs. a privileged user) own the /usr/ports hierarchy, I see thing like: /usr/local/sbin/portmaster -aF ===>>> Starting check of installed ports for available updates ===>>> Launching child to update boehm-gc-7.6.2 to boehm-gc-7.6.4 ===>>> All >> boehm-gc-7.6.2 (1/1) 0;portmaster: All >> boehm-gc-7.6.2 (1/1)^G ===>>> Currently installed version: boehm-gc-7.6.2 ===>>> Port directory: /usr/ports/devel/boehm-gc ===>>> Insufficient privileges to install ports (run as root or set PM_SU_CMD) ===>>> Aborting update ===>>> Update for boehm-gc-7.6.2 failed ===>>> Aborting update which seems a little silly, since I'm not trying to install anything. :-) I've attached a patch that seems to work for me. This was tested with portmaster at r461586, on a system running stable/11, amd64, at r330373. The ports tree was at r464069 at the time.
Fetch will in general also require privileges, unless you make your distfiles directory writable for the user running portmaster. I could implement a test for write-ability and skip asking for privileges, if that directory is found to be writeable. Since I'm currently abroad, I'll probably not be able to work on this issue for some 10 days.
While fetch can require privileges, the need for same will be quite evident quickly -- unlike the case of actually updating ports, where the first port may require significant time to build (e.g., www/chromium). I have no objection to portmaster testing for requisite write-ability; I just don't think it's as useful for fetch as checking for requisite privilege is for an update. And the current check breaks invocation of "portmaster -aF" via an unprivileged user's crontab entry, for example. (I had been doing this successfully for some time. I noted the issue a few weeks ago, but didn't get around to actually looking at it until yesterday.) No hurry -- the patch works for my case.
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ee6d1b3625ea80fdf178080aa0f14ad3f21757e1 commit ee6d1b3625ea80fdf178080aa0f14ad3f21757e1 Author: Stefan Eßer <se@FreeBSD.org> AuthorDate: 2024-11-01 20:20:20 +0000 Commit: Stefan Eßer <se@FreeBSD.org> CommitDate: 2024-11-01 20:20:20 +0000 ports-mgmt/portmaster: allow unprivileged users to fetch distfiles Allow portmaster -F to be run without requesting root privileges. Keep the testing of the user id as a separate test in order to not execute $PM_SU_CMD if $NO_ACTION" or $FETCH_ONLY is set. The distfiles directory must be writeable to take advantage of this change. PR: 226506 Reported by: David Wolfskill ports-mgmt/portmaster/Makefile | 3 +-- ports-mgmt/portmaster/distinfo | 6 +++--- 2 files changed, 4 insertions(+), 5 deletions(-)
Sorry for forgetting to test the proposed patch back in 2018 and to follow-up on this request ... I have not added further tests (e.g., to make this exception depend on a writable distfiles directory) and I have not updated the man-page, yet.