On 03/11/12 14:38, Martin Panter wrote:
On 3 November 2012 04:25, Dave Reisner <d@falconindy.com> wrote:
On Sat, Nov 03, 2012 at 04:13:02AM +0000, Martin Panter wrote:
On 3 November 2012 01:57, Dave Reisner <d@falconindy.com> wrote:
On Wed, Oct 31, 2012 at 07:06:13AM +0000, Martin Panter wrote:
Unmangled version: https://github.com/vadmium/pacman-arch/commit/b984a8b.patch
Turns out it wasn’t too hard to allow spaces in the path returned from “command -v”, while handling any extra arguments.
From b984a8b2cb3daa05177420d1a9d83648d6c0aa0d Mon Sep 17 00:00:00 2001 From: Martin Panter <vadmium à gmail·com> Date: Wed, 31 Oct 2012 02:45:36 +0000 Subject: [PATCH] Save path to Pacman, which could be lost during --syncdeps operation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit
Access to the Pacman command could be lost when /etc/profile is invoked and $PATH is reset. Tested to make sure the following scenarios behave sensibly, where “roopwn” is in ~/bin/:
PACMAN="pacman --config /etc/pacman.conf" makepkg --syncdeps --install PACMAN="nonexistent --dummy" makepkg --syncdeps --install PACMAN="nonexistent --dummy" makepkg PACMAN="roopwn --verbose" makepkg --syncdeps --install
NAK'ing this as well, based on feedback from the prior patch. This is the wrong approach to extending invocations to pacman.
Is your problem just that this perpetuates the custom arguments in the $PACMAN variable? If we got rid of the custom arguments support, this patch would have been a lot simpler, probably similar to just this hunk:
Right. PACMAN defines a command, not a command and options.
I'm a little confused as to why this would be needed. Presumably, pacman is in /usr/bin. If that falls out of your PATH, you're going to have much larger problems, and it won't only be pacman which is no longer accessible. Could you perhaps expand on your use case and why/how you ran into this problem?
Also mentioned my earlier thread (https://mailman.archlinux.org/pipermail/pacman-dev/2012-October/016021.html), but I shall expand here.
I have a Pacman wrapper called “roopwn” that I am playing with, linked in my ~/bin/ directory. This seems to me to be a nice way to use it as I develop it.
So my original problem was that if the --syncdeps operation gets run, I get some odd error messages, and the --install operation doesn’t automatically work:
<snip> I still find it a bit strange to have a system package management app outside of the system PATH but I have no objections to supporting this. Of course, you could use "PACMAN=~/bin/roopwn". Anyway, I think we would be fine with the following to patches: 1) A patch that replaces the PACMAN value with the full path to avoid your issues. There is no need to support adding options to that command - in fact... don't - it should be just the command. 2) A patch that allows PACMAN_OPT to be used to pass options to the PACMAN command. @Dave: have I interpreted your opinions correctly? Allan