Dan McGee wrote: > On Tue, Nov 10, 2009 at 4:36 PM, Allan McRae <[email protected]> wrote: >> Cedric Staniewski wrote: >>> Dan McGee wrote: >>>> On Fri, Nov 6, 2009 at 2:51 PM, Cedric Staniewski <[email protected]> wrote: >>>>> Implements FS#13028. >>>>> >>>>> Signed-off-by: Cedric Staniewski <[email protected]> >>>>> --- >>>>> 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.
