fix(rpm): own app/runtime dirs so the jpackage launcher finds its .cfg#369
Merged
Conversation
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).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Installing the RPM on Fedora/RHEL and launching the app fails with:
(issue #251)
Root cause
electron-builder builds RPMs via fpm, which lists only files and never emits
%direntries for the app's own directory tree. The jpackage launcher (libapplauncher.so,Package.cpp::initAppLauncher) discovers the app and runtime directories by runningrpm -ql <pkg>and matching lines thatendsWith/appand/runtime:With no directory entries, those scans return nothing →
appDir/runtimeDirstay empty → the launcher can't resolve its.cfg. DEB was never affected becausedpkg -Lalready lists directories.Fix
Pass fpm's
--rpm-auto-add-directoriesin the generated electron-builderrpm:config so fpm owns every payload directory (while still excluding the standard filesystem-package dirs via its bundledfilesystem_list), mirroring what jpackage's owntemplate.specdoes withcomm -23against thefilesystempackage.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:
rpm -qlplists only files — no/appor/runtimedirectory entries.rpm -qlplists…/lib/appand…/lib/runtimedirectory entries → launcher resolves the.cfg./opt,/usr,/usr/bin,/usr/share,/usr/share/applications,/usr/share/icons) are correctly excluded — no conflict with thefilesystempackage./usr/share/icons/hicolor/*, which is safe (rpm reference-counts directory ownership; only differing regular files conflict).Launcher behavior confirmed against OpenJDK
Package.cppand the builtlibapplauncher.so(containsrpm -ql ',dpkg -L ',tstrings::endsWith).Tests
Adds
ElectronBuilderRpmConfigTest— the RPM config emits the flag, it coexists withrpm.depends, and the DEB config does not emit the rpm-only flag.Note
Addresses the launcher
.cfgerror in #251. The separate "installer downloaded the RPM but failed to install" symptom in that issue is unrelated to%direntries (it's a silent-failure bug in thenucleus-websiteinstall script + missing demo assets on some releases) and is handled separately.