PKGBUILD creation and best practices

Jorgen_10 · 2025-05-02 12:21:20

Hi. This is my first time making a PKGBUILD and i was wondering about best practices and such.
As it currently stands, it's using electron-builder from the npm package list.
I checked the wiki for PKGBUILDs that use electron, along with checking other electron applications (e.g spotify, discord, and visual studio code) on how they do it, but become none the wiser.
Hence why I am now here. Another question I have is if it is fine to generate the desktop entry the way I'm currently doing it.
Also wondering if there is anything else that needs to be changed regarding conflicts and such with freeshow-bin
Are there any other suggested changes on top of what is already mentioned?

pkgname=freeshow
pkgver=1.4.1 # Update for each version
pkgrel=1 # Only update if the package didn't update, while the PKGBUILD itself did. (notifies users of an update without changing versions)
pkgdesc="Free software with a user-friendly interface that offers powerful features for creating and editing slideshows"
arch=('x86_64')
url="http://github.com/ChurchApps/FreeShow"
provides=('')
options=('!debug')
license=('GPL3')
depends=('electron' 'libx11' 'gtk3' 'alsa-lib' 'nss' 'libxss')
makedepends=('npm' 'nodejs' 'fakeroot')
source=("$pkgname-$pkgver.tar.gz::http://github.com/ChurchApps/FreeShow/archive/refs/tags/v$pkgver.tar.gz")  # Source tarball
sha256sums=('7d622648c05b0035d44ed984df9d4df1a85a1a77016bb70d6a9120a4b7853946')  # Replace with checksum of the source. (the archived tar ball)

# Build Process
prepare() {
  mv "$srcdir/FreeShow-$pkgver" "$srcdir/$pkgname-$pkgver"
  cd "$srcdir/$pkgname-$pkgver"
  # Generate desktop entry
  cat <<EOF > freeshow.desktop
[Desktop Entry]
Name=FreeShow
Description=Free software with a user-friendly interface that offers powerful features for creating and editing slideshows
Exec=freeshow %U
Icon=/usr/share/icons/hicolor/256x256/apps/freeshow.png
Terminal=false
Type=Application
Categories=Utility;Music;Video;
StartupWMClass=freeshow
EOF

# Install node packages
  npm install
}

build() {
  cd "$srcdir/$pkgname-$pkgver"

  # runs build
  npm run build
  # Ensures that Appimage and .deb package isnt built (along with avoiding github releases)
  npx electron-builder --config config/building/electron-builder.yaml --publish never --linux dir
}

package() {
  # Installation directory (defaults to /opt/freeshow)
  install -d "$pkgdir/opt/$pkgname"
  
  # Copy the contents of dist (from build) into /opt/freeshow
  cp -r "$srcdir/$pkgname-$pkgver/dist/linux-unpacked/"* "$pkgdir/opt/$pkgname/"

  # Install the freeshow executable to /usr/bin for easy terminal access
  install -d "$pkgdir/usr/bin"
  ln -sf "/opt/$pkgname/freeshow" "$pkgdir/usr/bin/freeshow"

  # Install the .desktop file for launcher integration (if you have one)
  install -d "$pkgdir/usr/share/applications"
  cp "$srcdir/$pkgname-$pkgver/freeshow.desktop" "$pkgdir/usr/share/applications/"

  # Install application icon
  install -d "$pkgdir/usr/share/icons/hicolor/256x256/apps"
  cp "$srcdir/$pkgname-$pkgver/src/server/icon.png" "$pkgdir/usr/share/icons/hicolor/256x256/apps/$pkgname.png"
}

Last edited by Jorgen_10 (2025-05-02 12:22:08)

cfr · 2025-05-02 12:54:47

I believe /opt is for binary blobs, so a source build probably doesn't belong there?

Jorgen_10 · 2025-05-02 12:59:21

cfr wrote:

I believe /opt is for binary blobs, so a source build probably doesn't belong there?

I checked the /opt folder for it's contents, and Visual Studio Code, Spotify and Discord resides there. Seeing how they are all Electron based, i also assumed thats where it goes. The files after the build seem to be the same as the ones residing in the /opt folder.
Some changes i do see that i should do though is to clone it with git rather than using a tar archive from the release builds.

EDIT: To provide source on this: http://wiki.archlinux.org/title/Electr … _structure

If the package contains a prebuilt copy of electron, copy the final distribution in its entirety to /opt/appname.

Last edited by Jorgen_10 (2025-05-02 15:23:49)

Lone_Wolf · 2025-05-03 12:19:10

http://wiki.archlinux.org/title/Arch_p … guidelines gives a good overview (and does have a section on directories)

Jorgen_10 · 2025-05-03 14:24:27

Thanks. That is very much helpful. I have updated a few things (like using git instead of an archive). Also used namcap --info to figure out more exact dependencies. Apparently I also forgot to put the LICENSE file into the expected folder. So the updated PKGBUILD is now: http://0x0.st/84tV.txt
For some reason upstream unpacks the asar file for dependencies (which i find weird), so I plan to ask them about that due to namcap giving warnings about the node-modules folder in asar-unpacked.

Jorgen_10 · 2025-05-03 22:52:46

I find the dependency part quite difficult.
namcap seems to estimate which dependencies are needed and whatnot (the namcap suggestion is the current dependency line in the PKGBUILD), and the wiki also suggests ldd, but it grants a list of .so files without the packages which makes dependencies even more difficult.
My current PKGBUILD is: http://0x0.st/84gj.txt
Trying to find a viable shortcut, I became desperate and did something that is usually frowned upon in such scenarios. I asked an AI about it and got the following response (it also contains the question):
direct
The full command was:

ldd /path/to/binary | awk '{print $3}' | xargs pacman -Qo | grep "is owned by" | cut -d' ' -f5- | sort -u

The output of said command was: http://0x0.st/84g2.txt
To be clear, I have yet not updated the list based on the output.
Is this an output i can trust or not? I generally have no idea how to figure out all the dependencies otherwise.
Still dont know which are optional either. I'm set on trying to run this by the books, but it's really difficult seeing how it is my first time.

Last edited by Jorgen_10 (2025-05-03 23:19:27)

Lone_Wolf · 2025-05-04 10:48:02

the output still has version numbers so the command doesn't work as advertised by the AI .

namcap is far from perfect and in the old bug tracker there were bugs for it that were opened 10+ years ago and never got solved.
(they seem to have disappeared in the transfer of repos)

Its output should be treated as mediocre quality advise, nothing more.

ldd is bad in dealing with uninstalled dependencies and doesn't show how things are related.
lddtree from pax-utils is preferred over ldd 99.9% of the time by many.

Please post the log from the clean chroot build.

Jorgen_10 · 2025-05-04 11:38:59

For the record, due to my current PKGBUILD (unmodified from the previous post) saying it needs lib32-alsa-lib i had to enable Multilib during this build. The result after the build is: http://0x0.st/84Uk.txt
Still uncertain if it even is required. It was just suggested by namcap after all. Also more concerned about actually running the program than building it, as it's rather the runtime dependencies I'm worried about.

In fact, I'm uncertain how sanitized a chroot needs to be to consider that "Yep. In fact those are the dependencies it requires. No more, no less".
As for the output of

lddtree /usr/bin/freeshow

I got this: http://0x0.st/84U5.txt

I'm still however at the point where i don't know where which package each of those .so files come from. Besides libffmpeg though as it's provided by itself.
I'm at the point where any suggestions would be appreciated, as I wish to maintain this package in a proper way rather than turning a blind eye and saying "well it works for me".

Trilby · 2025-05-04 12:43:44

I don't know if that dependency test command you found will work well or not, but I can say that several of the steps of that pipeline are just completely absurd and make no sense at all - though in their defense those ridiculous commands are likely effective 'noops' that do nothing at all. Was that AI generated? It looks like AI nonsense.

Here's a script I've used for the same purposes:

#!/bin/sh

readelf -d $1 \
	| sed -n 's|.*Shared library: \[\([^\]*\)\]|/usr/lib/\1|p' \
	| pacman -F - | sed 's|^|/|;s| .*||' | pacman -Qqo - \
	| sort -u

Pass the binary as the first parameter to this script, and it should give a proper list of packages providing all library dependencies.

Last edited by Trilby (2025-05-04 12:44:54)

Jorgen_10 · 2025-05-04 13:19:07

The command was in fact AI-generated, hence I haven't used them as the dependency list. As for your script, I get back

alsa-lib
at-spi2-core
cairo
dbus
expat
gcc-libs
glib2
glibc
gtk3
libcups
libdrm
libx11
libxcb
libxcomposite
libxdamage
libxext
libxfixes
libxkbcommon
libxrandr
mesa
nspr
nss
pango

Is this list more exact then? And would these be runtime dependencies? Looking at it, it reveals that all of these can be found within my current, along with some 32bit versions of these. so namcap seems to closely agree (besides clearly missing some x86-64 context)

Last edited by Jorgen_10 (2025-05-04 13:25:21)

Trilby · 2025-05-04 17:29:34

Jorgen_10 wrote:

Is this list more exact then?

I'm not sure how something could be "more" exact. It is either right or wrong. No script is perfect, but I have a high degree of confidence in the one I wrote - I have absolutely no confidence whatsoever in a script written by AI, nor should you.

Jorgen_10 wrote:

And would these be runtime dependencies?

Yes, that's all that can be meaningfully inferred from a built library.

Jorgen_10 · 2025-05-04 18:21:30

Thanks. For the help on dependencies. That's also why I asked here in the first place rather than blindly just agreeing to dependencies from any command. The wiki says to double check after all.

I have made changed the dependencies with the list given. Any other recommendations on the pkgbuild or should I mark this as solved?

Last edited by Jorgen_10 (2025-05-04 19:43:50)

Lone_Wolf · Yesterday 09:30:34

  # Generate desktop entry
  cat <<EOF > freeshow.desktop
[Desktop Entry]
Name=FreeShow
Description=Free software with a user-friendly interface that offers powerful features for creating and editing slideshows
Exec=freeshow %U
Icon=/usr/share/icons/hicolor/256x256/apps/freeshow.png
Terminal=false
Type=Application
Categories=Utility;Music;Video;
StartupWMClass=freeshow
EOF

In my opinion it's better to put that in a freeshow.desktop file that is added to the source array.
Doing that keeps the PKGBUILD shorter and cleaner .

# Install node packages
  npm install

Which node packages are needed and can they be replaced with repo packages ?

For those that can't be replaced, ensure they're downloaded to a temp location as described in http://wiki.archlinux.org/title/Node.j … rary_cache

EDIT

LICENSE wrote:

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

The correct SPDX identifier for that license would be GPL-3.0-or-later .

Last edited by Lone_Wolf (Yesterday 09:36:56)

Jorgen_10 · Yesterday 12:26:07

Just fixed up the desktop.

Also did a double check of the package.json for the dependencies:

    "dependencies": {
        "@discordjs/opus": "^0.10.0",
        "@googleapis/drive": "^8.16.0",
        "@sveltejs/svelte-virtual-list": "^3.0.1",
        "@vimeo/player": "^2.26.0",
        "adm-zip": "^0.5.16",
        "axios": "^1.9.0",
        "bonjour-service": "^1.3.0",
        "chord-transposer": "^3.0.9",
        "css-fonts": "^1.0.91",
        "dayjs": "^1.11.13",
        "ebml": "^3.0.0",
        "electron-store": "^8.2.0",
        "electron-updater": "^6.6.3",
        "exif": "^0.6.0",
        "express": "^4.21.2",
        "follow-redirects": "^1.15.9",
        "genius-lyrics": "^4.4.7",
        "grandiose": "github:vassbo/grandiose#5b1fc57",
        "jzz": "^1.9.3",
        "mp4box": "^0.5.4",
        "music-metadata": "^7.14.0",
        "node-machine-id": "^1.1.12",
        "osc-js": "^2.4.1",
        "pcm-convert": "^1.6.5",
        "pdfjs-dist": "^5.2.133",
        "pptx2json": "^0.0.10",
        "protobufjs": "^7.5.0",
        "qrcode-generator": "^1.4.4",
        "slideshow": "github:vassbo/slideshow#224d50f",
        "socket.io": "^4.8.1",
        "socket.io-client": "^4.8.1",
        "sqlite-to-json": "^0.1.3",
        "sqlite3": "5.1.6",
        "svelte-youtube": "0.0.2",
        "uid": "^2.0.2",
        "word-extractor": "^1.0.4",
        "youtube-iframe": "^1.0.3"
    }

Some could likely be moved like for example sqlite. I'm not sure how I would proceed to safely take out the dependency from node and add it as a dependency from the system.
Unlike python packages, npm packages doesnt seem to have a prefix (not from what i see at least, though I may obviously be wrong).

After compilation, they seem to unpack the asar file that gets generated and use that for some of the dependencies.
Of course i asked upstream about this, and got the reply that some dependencies just didnt seem to work unless they unpacked it.
After a completed build i tried manually removing it, but the application really doesn't like that, so I'm not entirely sure

The things that are unpacked in the asar is the following:

@discordjs (opus format)
font-scanner
grandiose
jazz-midi
jszip
sqlite

I also have looked around on the wiki and seen the Electron packaging guidelines: http://wiki.archlinux.org/title/Electr … guidelines
It mentions:

Electron Packaging Guidelines wrote:

By default electron-builder downloads the entire electron version that is defined in the package management file (e.g. package.json).
This might not be desired if you want to use the system electron and save the bandwidth since you are going to throw away the electron binaries anyway.

I guess this is the downside of having a packager that doesn't really know how the tools that are within the application theyre trying to package works.

Last edited by Jorgen_10 (Yesterday 12:32:53)

Arch Linux

#1 2025-05-02 12:21:20

PKGBUILD creation and best practices

#2 2025-05-02 12:54:47

Re: PKGBUILD creation and best practices

#3 2025-05-02 12:59:21

Re: PKGBUILD creation and best practices

#4 2025-05-03 12:19:10

Re: PKGBUILD creation and best practices

#5 2025-05-03 14:24:27

Re: PKGBUILD creation and best practices

#6 2025-05-03 22:52:46

Re: PKGBUILD creation and best practices

#7 2025-05-04 10:48:02

Re: PKGBUILD creation and best practices

#8 2025-05-04 11:38:59

Re: PKGBUILD creation and best practices

#9 2025-05-04 12:43:44

Re: PKGBUILD creation and best practices

#10 2025-05-04 13:19:07

Re: PKGBUILD creation and best practices

#11 2025-05-04 17:29:34

Re: PKGBUILD creation and best practices

#12 2025-05-04 18:21:30

Re: PKGBUILD creation and best practices

#13 Yesterday 09:30:34

Re: PKGBUILD creation and best practices

#14 Yesterday 12:26:07

Re: PKGBUILD creation and best practices

Board footer