On 03/11/12 14:38, Martin Panter wrote: > On 3 November 2012 04:25, Dave Reisner <[email protected]> wrote: >> On Sat, Nov 03, 2012 at 04:13:02AM +0000, Martin Panter wrote: >>> On 3 November 2012 01:57, Dave Reisner <[email protected]> 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
