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

[Allan McRae]

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?

Allan