On 31 October 2012 02:28, Martin Panter <vadmium+patch@gmail.com> wrote:
On 31/10/2012, Allan McRae <allan@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).