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).
> 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.
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.