[pacman-dev] [PATCH] Use absolute path for pacman and pacman-conf in makepkg

wwijsman at live.nl wwijsman at live.nl
Mon May 11 13:01:22 UTC 2020

On Mon, 2020-05-11 at 12:42 +1000, Allan McRae wrote:
> On 8/5/20 4:13 am, Wouter Wijsman wrote:
> > Currently makepkg requires pacman and pacman-conf to be in the path
> > of
> > the user. Since these executables should never move, it should be
> > safe
> > to add the full paths to the scripts at compile time, assuming the
> > user
> > uses the install command as well.
> > 
> > This change works for both autotools and meson.
> > 
> > Signed-off-by: Wouter Wijsman <wwijsman at live.nl>
> > ---
> Hi,
> Can you let us know more detail about the use case for this
> patch?  Why
> would the user not add the directory pacman and scripts are installed
> in
> to their path?
> I have concerns that hardcoding paths on build will lead to
> difficulty
> when in the future we have a test suite for makepkg.
> Allan


I've since realized that this patch is not really needed. It was
supposed to go together with another patch which didn't end up working.
Sorry for the spam.

I'm working on making pacman manage libraries for the Playstation
Portable in a homebrew PSP software development kit. For this to work
on both systems which already have pacman and systems which do not, I
initially tried to make pacman build with different binary names. This
approach had many issues and would require forking, which I'm not keen
on doing. The Playstation Vita homebrew SDK and the devkit pro
(multiple systems, mostly Nintendo) also use pacman, but they have
these forks which are old and have some bugs not found in upstream

Now I'm working on a different solution, which is to change the bindir
in the meson options while building (to keep the binaries out of the
path of the user) and using wrapper scripts for pacman and makepkg. Now
I realize that I can just set the path in the wrapper script and be
done with the issue this patch was supposed to solve.

Right now an unpatched pacman almost works for my use case, but there
still is one issue with building it. Currently ninja will install the
bash-completion scripts system wide, regardless of which user runs
ninja install or what the prefix is. Only if bash-completion is not
available, will the scripts be installed inside the prefix. The code
which makes this happen is here: 

This is why I submitted the patch which makes bash-completion optional.
It may need a different solution, though. Would you take a patch which
adds an option to install the bash-completion scripts inside the
prefix? I'd prefer not to maintain any private patches if that's

Kind regards,

P.S. For the people interested in the wrapper, here is a link: 

The pacman.sh script builds and installs pacman. The wrapper scripts
are in scripts. If the user already has pacman, it doesn't build it at
all and the wrapper will use the system's pacman with a different
configuration, root and dbpath.

More information about the pacman-dev mailing list