[pacman-dev] [PATCH 2/2] makepkg: add a config file option for the pacman binary to be used

[Cedric Staniewski]

Dan McGee wrote:
> On Tue, Nov 10, 2009 at 4:36 PM, Allan McRae <allan at archlinux.org> wrote:
>> Cedric Staniewski wrote:
>>> Dan McGee wrote:
>>>> On Fri, Nov 6, 2009 at 2:51 PM, Cedric Staniewski <cedric at gmx.ca> wrote:
>>>>> Implements FS#13028.
>>>>>
>>>>> Signed-off-by: Cedric Staniewski <cedric at gmx.ca>
>>>>> ---
>>>>> Oops... forgot to adjust the documentation. -T support is not required
>>>>> anymore for the pacman wrappers.
>>>> I think I'd rather see this as an environment variable- wouldn't that
>>>> make more sense, as we wouldn't require it to be specified by the vast
>>>> majority of people that just want to use the default?
>>>>
>>>> PACMAN=${PACMAN:-pacman} or whatever it is.
>>>>
>>>> -Dan
>>> Sorry Dan, but I do not get your point. This patch makes it possible to
>>> specify a pacman command in one of the makepkg.conf files, but it is not
>>> mandatory because of the reason you mentioned. I already use your line in my
>>> patch:
>>>
>>> +# set pacman command if not defined in config files
>>> +PACMAN=${PACMAN:-pacman}
>>> +
>>>
>>> It is, however, not possible to provide a pacman command via environment
>>> variable, because I think it makes more sense to store it in a config file.
>>> So do you mean it should be possible to use an environment variable as
>>> well?
>> I think Dan wants it to only be available through and environmental variable
>> and not in the makepkg.conf.  That should already be possible with your
>> patch (as you point out, the line Dan suggested is already there).
>>
>> I have no real preference but am leaning towards it not being included in
>> pacman.conf given the usage is expected to be low.  If we are wrong and it
>> becomes very popular to use some wrapper, then we can always add the config
>> option later.
> 
> My suggestion was as Allan says; only do it in the environment. Of
> course, since makepkg.conf is just sourced anyway, then to each his
> own, but I'd rather not advertise it there at all.
> 
> Why? Things like $BROWSER, $EDITOR, etc. are pretty standard and
> accepted variables. There is no reason that on an Arch system, $PACMAN
> shouldn't join that list. This would address other things, such as
> people always wanting to have it run with a certain command line flag,
> or perhaps always use a pacman.static binary, or anything like that.
> Maybe I'm making orange juice out of bananas, but yeah.
> 
> -Dan
> 

I'm fine with your approach and it would definitely have some
advantages, however I prefer documenting it somewhere. My worry is that
we run into side-effects when someone has set this variable to something
weird for some obscure reasons, but perhaps I am a bit too pessimistic here.