Re: [pacman-dev] [PATCH] Use absolute path for pacman and pacman-conf in makepkg
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 > > --- > > 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 Hi, 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 pacman. 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: https://git.archlinux.org/pacman.git/tree/meson.build#n46 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 possible. Kind regards, Wouter P.S. For the people interested in the wrapper, here is a link: https://github.com/sharkwouter/psp-pacman-1/tree/upstream-pr 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.
Re: [pacman-dev] [PATCH] Make bash-completion optional
On Thu, 2020-05-07 at 15:21 -0400, Eli Schwartz wrote: > The problem should only happen during install, not during build. I > presume that it is trying to install to e.g. > /usr/share/bash-completion/completions/pacman and raising a > PermissionError? That is true, my bad, it only fails upon installation and only if you deny it root access. /usr/share/bash-completion is used regardless of prefix for both build systems, so I assumed that was intended, especially since it wouldn't work if it was in any other place. Kind regards, Wouter Wijsman
Re: [pacman-dev] Bug: using --program-prefix configure option breaks makepkg
On Mon, 2020-05-04 at 10:54 -0400, Eli Schwartz wrote:
> On 5/4/20 10:39 AM, Wouter Wijsman wrote:
> > Hi Pacman team,
> >
> > In the last couple of days I've been trying to build pacman for use
> > with a homebrew sdk for the Playstation portable. The idea is for
> > it
> > to allow sharing of libraries for the system. To make sure this
> > version of pacman doesn't collide with the system's, I use the
> > --program-prefix option for the configure script, which adds "psp-"
> > in front of all binary names.
> >
> > Now when using the --program-prefix option, makepkg is no longer
> > able
> > to work. This because it has the name for the pacman executable
> > name
> > hardcoded it seems.
>
> I've never really experimented with --program-prefix, but I expect
> the
> general way to do this would be to add those executable names as
> replacements to build-aux/edit-script.sh.in (meson) and
> scripts/Makefile.am $(edit) (autotools). Is there e.g. a variable set
> in
> the configured Makefile which describes this prefix and can be used
> to
> define a replacement?
>
> Do you know of any examples of other autotools projects which invoke
> internal programs via shellscripts and have handled this before?
>
>
> I think for meson, this would need to be explicitly added as AFAIK
> meson
> doesn't have a comparable feature anyway.
Thanks for the info! I did manage to fix it for autotools in the way
gcc does it, for which I've submitted a patch now, but I think you're
right about Meson. I don't really know much about Meson, though. Are
you guys planning on keeping autotools supported or is Meson the
future?
> > I compile with the following commands: ./configure --
> > prefix=${PSPDEV}
> > --with-buildscript=PSPBUILD --with-root-dir=${PSPDEV}/psp
> > --program-prefix="psp-" --disable-doc make make install
> >
> > For this to work, I require the following patch:
> > https://github.com/sharkwouter/psptoolchain/blob/psp-pacman/patches/pacman-5.2.1.patch
> >
> > Is there a way to prevent me from needing this patch? Besides this
> > patch, the pacman 5.2.1 tarball build and works fine for my
> > purposes.
> >
> > P.S. I did find another small annoyance. Which is that "make
> > install"
> > fails if the bash completion files are already installed.
>
> Is this because of:
>
> for completion in makepkg pacman-key; do \
> $(LN_S) pacman $(DESTDIR)/$(bashcompdir)/$$completion; \
> done
>
> Because if so, you can probably get it to work by defining LN_S to
> add
> the -f flag.
It seems this can be set in libtool.m4, but that's generated/added by
autoreconf it seems, so I don't know if that would work. I'll probably
add a workaround to my build script :/
