On Sat, Nov 03, 2012 at 02:55:07PM +1000, Allan McRae wrote: > 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?
Yup, spot on. d
