[pacman-dev] [PATCH 2/2] Save path to Pacman, which could be lost during --syncdeps operation

[Dave Reisner]

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 <d at 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 at 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?

Yup, spot on.

d