Package Details: duckstation-git 0.1.r9409.g168b80dd4-1

Git Clone URL: https://aur.archlinux.org/duckstation-git.git (read-only, click to copy)
Package Base: duckstation-git
Description: A Sony PlayStation (PSX) emulator, focusing on playability, speed, and long-term maintainability (git version)
Upstream URL: https://github.com/stenzek/duckstation
Keywords: emulator game gaming psone psx
Licenses: cc-by-nc-nd-4.0
Conflicts: duckstation
Provides: duckstation
Submitter: jackdroido
Maintainer: eugene
Last Packager: eugene
Votes: 30
Popularity: 0.70
First Submitted: 2020-04-25 18:24 (UTC)
Last Updated: 2025-09-04 11:12 (UTC)

Dependencies (45)

Required by (0)

Sources (11)

Pinned Comments

eugene commented on 2025-09-03 18:12 (UTC)

The 'versions' file now includes a curious disclaimer that specifically forbids any packaging scripts from using it.

PN123 commented on 2025-09-03 17:44 (UTC)

Stumbled upon a problem in prepare() while trying to update:

The build fails at this grep. It doesn't find anything because the version strings have been moved to a different file. 

dep_ver=$(grep -Po "(?<=^$dep_var=).+" "$deps_script" )

They are now listed here: $srcdir/duckstation/scripts/deps/versions

Latest Comments

1 2 3 4 5 6 .. 16 Next › Last »

raziel100 commented on 2025-09-04 18:47 (UTC)

So, the way to help fix the issue between us and him, is to break this pkgbuild, making more difficult for someone to use it? because even the dep_ver issue that had already been apointed by hadn't been adressed at all, the build is still failing because of the changes in upstream, nothing was adressed, is still broken, just that now is even more broken than before

HurricanePootis commented on 2025-09-04 16:03 (UTC)

@loathingkernel

In my CMake arguments, I'm doing stuff like -DSDL3_DIR="$srcdir/build-deps/lib/blah/blah/blah, in the end, that ends up linking my duckstation-qt to the specific location of the binary. However, since you did -DCMAKE_PREFIX_PATH="$PWD"/build-deps \ it somehow changes the behavior. I don't know which method of doing is "more correct". But, I will look into it cause it seems a lot simpler.

loathingkernel commented on 2025-09-04 14:53 (UTC) (edited on 2025-09-04 14:54 (UTC) by loathingkernel)

I disagree about the location part. Your software shouldn't change how it runs depending on where it is installed.

I am not going to argue against or for this, in theory I agree with you, but given the situation with this package, it is just easier to go with upstream's flow on this one.

it would point to libSDL3.so.0 installed in my /home/hurricane/duckstation-git/src/build-deps/... folder.

Running ldd on the duckstation-qt binary from the build I quoted below shows that RPATH works correctly

loathingkernel@host duckstation $ ldd duckstation-qt | grep "/opt"
    libplutosvg.so.0 => /opt/duckstation/libplutosvg.so.0 (0x00007ffbe1993000)
    libsoundtouch.so.2 => /opt/duckstation/libsoundtouch.so.2 (0x00007ffbe2166000)
    libSDL3.so.0 => /opt/duckstation/libSDL3.so.0 (0x00007ffbe1200000)
    libcpuinfo.so => /opt/duckstation/libcpuinfo.so (0x00007ffbe2156000)

so I can't say that I am observing this behavior. To me it seems that whatever is built locally (in relation to the package) is RPATH'd correctly. I do notice the lack of libshaderc_ds from the ldd output completely though in my case. Duckstation itself does work correctly though, so I am not sure what is going on here.

And yes, using patchelf if required to fix library loading would ultimately be considered proper packaging, that's not an issue in any way imo.

HurricanePootis commented on 2025-09-04 12:47 (UTC) (edited on 2025-09-04 12:47 (UTC) by HurricanePootis)

@loathingkernel

I disagree about the location part. Your software shouldn't change how it runs depending on where it is installed. However, you are spot on about just using the damn build script provided.

It's so nice just to use the script and not having to do some crazy ass bash parsing whenever you'll end up with the same result. Now, I did have to use patchelf to:

  1. Actually get the binary to point to the installed libraries once installed. For example, whenever duckstation is built with the provided buildscript, it would point to libSDL3.so.0 installed in my /home/hurricane/duckstation-git/src/build-deps/... folder. Maybe this is why the AUR maintainers went with a weird bash loop? Regardless, all I had to do was to use patchelf to point the duckstation binary to the built library's installed location.
  2. Add the shaderc as a library for wayland support. For some reason, duckstation's binary did say it was linked to the shaderc it built (checked with lld). Therefore, I just added it to the binary with patchelf.

Of course, I'm still using the provided libraries from the output of his build script. But, to be honest, using patchelf to get the libraries to actually load seems like a much more conformant way of packaging his software.

Now, if this PKGBUILD was to change to respect his wishes more, I don't know if he would stop this arms race between the AUR and himself. There has been a lot of disrespect on both sides.

loathingkernel commented on 2025-09-04 10:01 (UTC) (edited on 2025-09-04 10:07 (UTC) by loathingkernel)

I have been watching this package and conversation for some time now, and I can't help but wonder why you are creating a maintenance hell for yourselves.

I mean, for one you are doing something which the developer doesn't want you to do, but that's really not the point. I kind agree with you that having a build recipe on AUR to build it doesn't affect the developer. But your insistence on trying to place it under /usr/lib is honestly causing you so many problems.

Just place it under /opt (like it was for the longest time), build the dependencies through the provided script as intended, and keep them all together in the same location. And be done with it. You are trying to adhere to a "unix philosophy" which makes no sense here, the application it meant to be distributed as is, at the very least stop fighting against the upstream development, you are not providing a service to anyone this way.

For the record, my own local package is simply doing the following and it has had no issues so far with building, neither any need for all the weirdo workarounds in the PKGBUILD

build() {

    ./duckstation/scripts/deps/build-dependencies-linux.sh \
      -system-freetype -system-harfbuzz -system-libjpeg \
      -system-libpng -system-libwebp -system-libzip \
      -system-zlib -system-zstd -system-qt \
      "$PWD"/build-deps

    unset DEBUGINFOD_URLS
    cmake -B build -S duckstation \
        -G Ninja \
        -Wno-dev \
        -DCMAKE_BUILD_TYPE=Release \
        -DCMAKE_C_COMPILER=clang \
        -DCMAKE_CXX_COMPILER=clang++ \
        -DCMAKE_EXE_LINKER_FLAGS_INIT="-fuse-ld=lld" \
        -DCMAKE_MODULE_LINKER_FLAGS_INIT="-fuse-ld=lld" \
        -DCMAKE_SHARED_LINKER_FLAGS_INIT="-fuse-ld=lld" \
        -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=ON \
        -DCMAKE_PREFIX_PATH="$PWD"/build-deps \
        -DALLOW_INSTALL=ON \
        -DINSTALL_SELF_CONTAINED=ON \
        -DCMAKE_INSTALL_PREFIX="${pkgdir}"/opt/duckstation
    ninja -C build
}

eugene commented on 2025-09-04 09:54 (UTC)

stenzek just put another hidden mine as part of 4b472dd. This guy is sick

Neros commented on 2025-09-04 09:39 (UTC)

@eugene thanks now I can build it but... when launching duckstation-qt there are 2 error windows saying "Resources are missing, your installation is incomplete" and "Failed to initialize config." and it closes.

eugene commented on 2025-09-04 04:07 (UTC)

My bad, @Neros — totally forgot the build part was still the build part. That one's on me.

HurricanePootis commented on 2025-09-03 22:48 (UTC)

You guys can always manually handle deps.

Neros commented on 2025-09-03 22:01 (UTC)

Even with the new fix (I set the path) I can't build it:

==> Starting build()...
==> ERROR: A failure occurred in build().
    Aborting...

I don't know if I'm doing something wrong or if it's something else

1 2 3 4 5 6 .. 16 Next › Last »