Skip to content

fix(rpm): own app/runtime dirs so the jpackage launcher finds its .cfg#369

Merged
kdroidFilter merged 1 commit into
mainfrom
fix/rpm-app-dir-entries
Jul 18, 2026
Merged

fix(rpm): own app/runtime dirs so the jpackage launcher finds its .cfg#369
kdroidFilter merged 1 commit into
mainfrom
fix/rpm-app-dir-entries

Conversation

@kdroidFilter

Copy link
Copy Markdown
Collaborator

Problem

Installing the RPM on Fedora/RHEL and launching the app fails with:

Error opening "NucleusDemo.cfg" file: No such file or directory

(issue #251)

Root cause

electron-builder builds RPMs via fpm, which lists only files and never emits %dir entries for the app's own directory tree. The jpackage launcher (libapplauncher.so, Package.cpp::initAppLauncher) discovers the app and runtime directories by running rpm -ql <pkg> and matching lines that endsWith /app and /runtime:

// RPM: "rpm -ql '" + name + "'"
if (tstrings::endsWith(line, "/app"))     { appDir = line; }
if (tstrings::endsWith(line, "/runtime")) { runtimeDir = line; }

With no directory entries, those scans return nothing → appDir/runtimeDir stay empty → the launcher can't resolve its .cfg. DEB was never affected because dpkg -L already lists directories.

Fix

Pass fpm's --rpm-auto-add-directories in the generated electron-builder rpm: config so fpm owns every payload directory (while still excluding the standard filesystem-package dirs via its bundled filesystem_list), mirroring what jpackage's own template.spec does with comm -23 against the filesystem package.

rpm:
  fpm:
    - "--rpm-auto-add-directories"

This replaces the heavyweight approach in #363 (extract + rebuild the RPM via rpmbuild) with a single, correct flag.

Verified

Reproduced with the exact fpm binary electron-builder caches:

  • Before: rpm -qlp lists only files — no /app or /runtime directory entries.
  • After: rpm -qlp lists …/lib/app and …/lib/runtime directory entries → launcher resolves the .cfg.
  • Filesystem-package dirs (/opt, /usr, /usr/bin, /usr/share, /usr/share/applications, /usr/share/icons) are correctly excluded — no conflict with the filesystem package.
  • Only co-owns /usr/share/icons/hicolor/*, which is safe (rpm reference-counts directory ownership; only differing regular files conflict).

Launcher behavior confirmed against OpenJDK Package.cpp and the built libapplauncher.so (contains rpm -ql ', dpkg -L ', tstrings::endsWith).

Tests

Adds ElectronBuilderRpmConfigTest — the RPM config emits the flag, it coexists with rpm.depends, and the DEB config does not emit the rpm-only flag.

Note

Addresses the launcher .cfg error in #251. The separate "installer downloaded the RPM but failed to install" symptom in that issue is unrelated to %dir entries (it's a silent-failure bug in the nucleus-website install script + missing demo assets on some releases) and is handled separately.

electron-builder builds RPMs via fpm, which lists only files and never emits
%dir entries for the app's own directory tree. The jpackage launcher
(libapplauncher.so, Package.cpp::initAppLauncher) discovers the app and runtime
directories by running `rpm -ql <pkg>` and matching lines that endWith "/app"
and "/runtime"; with no directory entries those scans return nothing, so the
launcher cannot resolve its .cfg and dies with
`Error opening "<app>.cfg" file: No such file or directory` on Fedora/RHEL.

Pass fpm's `--rpm-auto-add-directories` in the generated electron-builder rpm
config so fpm owns every payload directory (while still excluding the standard
filesystem-package dirs via its bundled filesystem_list), mirroring what
jpackage's own template.spec does with `comm -23` against the filesystem
package. DEB was never affected because `dpkg -L` already lists directories.

Addresses #251 (launcher .cfg error).
@kdroidFilter
kdroidFilter merged commit 35a8234 into main Jul 18, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant