PSP Pacman

[sharkwouter]

This PR adds the following commands:

• psp-pacman
• psp-makepkg

For this it downloads and patches the latest upstream pacman release. There is only 1 patch at the moment which only makes some changes to to build system and configuration files for both makepkg and pacman. These changes allow us to build and install pacman for our purposes.

On Arch the system's pacman will be used and pacman will not be build.

The root path for pacman is set to $PSPDEV. Our build scripts use PSPBUILD as name.

See the README.md file in this PR for more details on how to install and use it.

[carstene1ns]

Generally looks very good so far. Why putting pacman in ${PSPDEV}/share/pacman and not directly in ${PSPDEV}/pacman (like I did)?

[sharkwouter]

${PSPDEV}/share/pacman is where Linux distributions would package applications which have a wrapper. ${PSPDEV}/pacman seemed a bit strange to me.

[carstene1ns]

is where Linux distributions would package applications which have a wrapper.

Never heard of such convention.

[sharkwouter]

They do it because they try to follow the filesystem hierarchy standard, which says the following about /usr/share(similar to our ${PSPDEV}/share):

"Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally). It is recommended that a subdirectory be used in /usr/share for this purpose."

Source: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html

I think adhering to this standard as much as possible would be a good idea. We're already following it for most things. The psp and sdk directories can be exceptions here, as they are pretty much separate root filesystems. Although sdk could probably be a part of psp, but changing it could be very painful for users.

[carstene1ns]

These 2 points are enough against putting it in share:

• pacman changes files in this directory, it's database at least
• pacman is a binary

[sharkwouter]

Yeah, we should probably move the db to ${PSPDEV}/var.

I think the binaries should stay in its current place. They don't change and should never be used directly by the user. It's important to make sure the user never adds them to their path.

The configuration files should actually probably be in ${PSPDEV}/etc.

I wouldn't want to clutter the ${PSPDEV} directory with more directories, though.

[sharkwouter]

It's very common to have helper binaries which the user shouldn't use directly, but are needed by an application, in /use/share/applicationname/bin. On Debian that is the standard.

[sharkwouter]

What we could also do is using ${PSPDEV} as prefix and change the location of the bin dir instead of install everything in in a different location.

[sharkwouter]

I've just made some changes:

• Pacman is now installed in $PSPDEV, but the binaries are put into $PSPDEV/share/pacman/bin. This means we no longer have to worry about where files go.
• The wrapper scripts now change the path, making most of my patch absolete. This also allowed me to use the same pacman command regardless of which pacman we use using.
• The patch is no longer used. This does mean that the installation of the bash-completion files goes in the system wide path, causing build failures for non-sudo installs. I will look into this later and try to talk to upstream. Upstream seems to see this as a bug.

[carstene1ns]

This looks really better now! 👍

I think this is in a mergeable state now, but the bash-completion should be disabled until we reach a conclusion:

• It cannot be used in current state, as the commands are different
• It will need to be installed in system location to be used or the user is forced to do some symlinking/config change
• We should not overwrite files in locations only touched by the package manager (e.g. installing pacman on fedora/gentoo afterwards will fail, because files already present)

However, we have a real problem we need to deal with when building packages with having the root dir in mind.
All pkg-config files and tools like freetype-config, sdl-config, … will be broken, because the paths do not match.
We either need to:

• patch the tools/*.pc files (messy, but works)
• change the root dir to / (allows us to use the real paths, but can seriously mess up the system)
• fixup in the package() function (manually/with helper script in all PSPBUILDs)
• fixup after packaging (hook into some post-package() step like we did with psp-strip)

[sharkwouter]

I've added a patch which potentially fixes our issues with bash-completion while still making the files available. Savy users can make symlinks to them if they wish.

We could go for this option for now:

• "patch the tools/*.pc files (messy, but works)"

It is annoying, though, but changing the root dir to / would allow people to easily mess up their entire system. The Vita SDK does that, but I really dislike it.

Although this one could be a long term solution:

• "fixup after packaging (hook into some post-package() step like we did with psp-strip)"

How i'd see us do this is to make a psp-pkg-config wrapper which takes the root dir set for pacman into account. I'm not sure if we should let implementing this hold back merging it, though, since pkg-config, sdl-config and freetype-config are currently not extensively used by the community.

[carstene1ns]

I do not think it is a good idea to break stuff like this. Currently *-config binaries work, even if "the community" does not use them.
Changing the root dir is not a good idea, I already wrote that above.

I do not think you have an idea how much work it is to actually have this in a sane way (there might be hardcoded things around each library).

My approach for "fixup in the package() function (manually/with helper script in all PSPBUILDs)" (as a current solution until further improvments):
Use --prefix=$(psp-config --psp-prefix) for configure run in build(), as it makes sure the library hardcodes paths correctly everywhere
After make DESTDIR=$pkgdir install do this:

mv ${PSPDEV:1}/* $pkgdir
rm -r ${PSPDEV:1}

Which should move everything upwards relative to the root path.

[sharkwouter]

Yeah, you're right, we could come up with a solution for it.

I did find one which could work, but it does have some downsides. We can set the following either in the psp-makepkg script or makepkg.conf:

export PKG_CONFIG_SYSROOT_DIR=$PSPDEV
export PKG_CONFIG_PATH=$PSPDEV/psp/lib/pkgconfig

We would probably also need to set this in the toolchain file for cmake it's probably a good idea to set it in build.mak as well. Then users would be able to use pkg-config without needing a wrapper.

An example for jsoncpp build from this PSPBUILD:

wouter@wouter-pc:~$ PKG_CONFIG_SYSROOT_DIR=$PSPDEV PKG_CONFIG_PATH=$PSPDEV/psp/lib/pkgconfig pkg-config jsoncpp --cflags
-I/usr/local/pspdev/psp/include/jsoncpp

Here the contents of jsoncpp.pc:

libdir=/psp/lib
includedir=/psp/include/jsoncpp

Name: jsoncpp
Description: A C++ library for interacting with JSON
Version: 1.8.4
URL: https://github.com/open-source-parsers/jsoncpp
Libs: -L${libdir} -ljsoncpp
Cflags: -I${includedir}

[sharkwouter]

After some thinking, I'd say we should include this in the cmake toolchain file and makepkg.conf. In build.mak it wouldn't work, because it is usually included at the end of the user's Makefile. We need to have some instructions about how to set this up when building an EBOOT.PBP, though, but I'm not quite sure where we would put this.

[carstene1ns]

Autotools warns about using unprefixed tools nowadays, so this still needs to be addressed IMO.
My approach would be to do the same with psp-pkg-config like we did with pacman.
Have a wrapper and build pkg-conf-lite on systems without it (macos,...)

[sharkwouter]

Then I guess we need a different solution. I'll look into tricking makepkg to fix this for us then., so we can just tell people to use $PSPDEV/psp as prefix.