[pacman-dev] Fwd: [PATCH] Hack to detect Pacman-command-no-found error

[Martin Panter]

On 31 October 2012 02:28, Martin Panter <vadmium+patch at gmail.com> wrote:
> On 31/10/2012, Allan McRae <allan at archlinux.org> wrote:
>> Perhaps a better approach to this would be to check the program
>> specified in $PACMAN is available in the check_software function and
>> then assign it to its full path.  i.e. PACMAN=$(which $PACMAN)
>
> Sounds like that could be better. Then “makepkg --syncdeps” should
> actually be usable in the above case.

I’m working on a patch that does this. There is already code that
seems to check if Pacman is available for the --syncdeps operation, if
you search for “Skipping dependency checks”. So I will try to save the
path there, using “command -v”. Assuming this is more portable and
POSIX-y than “which”.

I ran into an inconsistency with the behaviour of spaces in $PACMAN.
Judging by the “${PACMAN%% *}” incantation from revision 66c6d28
(makepkg: allow to specify an alternative pacman command), it looks
like the original intention was to allow arguments after the command
name. I think restoring that is the best way forward but will mean
that the full path to $PACMAN will not be allowed to have spaces,
because supporting spaces in the path and also spaces to separate
arguments seems needlessly complex.

Currently, including arguments in $PACMAN means the --syncdeps
operation may be attempted, but each Pacman invocation will probably
fail. However in other cases the operation would be skipped if $PACMAN
cannot be found. Looks like this inconsistency comes from  revision
622326b (makepkg: fix sudo/su calling of pacman).