| Message ID | DM5PR18MB1401CF1B4BAE7DEFFD5765FAB3FF0@DM5PR18MB1401.namprd18.prod.outlook.com |
|---|---|
| State | Rejected, archived |
| Delegated to: | Andrew Gregory |
| Headers | show |
On May 28, 2017 00:40:25 Allan McRae <allan@archlinux.org> wrote: > On 25/05/17 12:16, Harley W wrote: >> This is in response to bug #33369 on Flyspray - "pacman asks for root password >> for -w option (download only)". > > What do you do with the downloaded packages that does not itself require > root access? > > I think this bug should just be closed. > > A Yeah, I agree. I mostly wanted to see if there's a better solution out there than what I was proposing. I guess I didn't think much about why someone would want to download a package that didn't require root access. Even if there was a reason, it's probably not common enough to really benefit from being able to run the pacman command without root privileges. Given the change in behavior associated with my patch I'd say it's really not worth it. Thanks for your feedback, I'll concur that the bug should be closed. -Harley Sent with AquaMail for Android http://www.aqua-mail.com
diff --git a/src/pacman/util.c b/src/pacman/util.c index ae8a74d3..f7f397fa 100644 --- a/src/pacman/util.c +++ b/src/pacman/util.c @@ -115,7 +115,7 @@ int needs_root(void) case PM_OP_SYNC: return (config->op_s_clean || config->op_s_sync || (!config->group && !config->op_s_info && !config->op_q_list && - !config->op_s_search && !config->print)); + !config->op_s_search && !config->print && !config->op_s_downloadonly)); case PM_OP_FILES: return config->op_s_sync; default:
Signed-off-by: DestructiveReasoning <harleyw@hotmail.com> --- This is in response to bug #33369 on Flyspray - "pacman asks for root password for -w option (download only)". I was looking into this tonight and ultimately encountered an issue that the lock file is (by default) stored under /usr, making it not writable for the average user. I am very new to C and concurrency (and pacman-dev ;) so I do not fully understand why the lockfile is necessary for a download-only operation, but assuming it is necessary, the only option I can think of to resolve the reported bug involves changing the permissions on the lockfile. I've included the very simple patch below that, in conjunction with changing the permissions on the lockfile, seem to fix the problem described in the bug. The only notable change of functionality that I've seen is that executing "$ pacman -Sw <package>" without modifying the cache directory will, since it cannot write to the default, write to /tmp rather than asking for a root password. However, now it is possible to execute "$ pacman -Sw <package> --cachedir=$HOME", for example, without being prompted for the root password. Please let me know what you think about this or if I've missed a much prettier alternative (which is likely). Cordially, Harley Wiltzer src/pacman/util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)