Bug Description
The current RPM packaging logic fails when the application's binary name (defined in linux/CMakeLists.txt) differs from the package name or the pubspec name.
- Inheritance Issue:
MakeRPMConfig extends MakeConfig directly, bypassing the logic in MakeLinuxPackageConfig that parses CMakeLists.txt to find the real BINARY_NAME. As a result, appBinaryName defaults to pubspec.name, causing broken paths if CMake defines a different name.
- Symlink Issue: The
%install script attempts to symlink files using incorrect names, leading to File not found errors during the build or broken symlinks after installation.
- Builder Inconsistency: AppPackageMakerRPM generates assets (icons, .desktop files) using the project name, but the binary is named differently
- Metainfo Mismatch: The metainfo logic already used appBinaryName, creating a mix of naming conventions in the BUILD directory.
Proposed Solution
- Change
MakeRPMConfig to extend MakeLinuxPackageConfig. This inherits the correct appBinaryName getter.
- Update the
%install section to create a symlink pointing to the real binary ($appBinaryName) but named after the package (%{name}).
- Update .png, .desktop, .xml to use
appBinaryName
Bug Description
The current RPM packaging logic fails when the application's binary name (defined in
linux/CMakeLists.txt) differs from the package name or the pubspec name.MakeRPMConfigextendsMakeConfigdirectly, bypassing the logic inMakeLinuxPackageConfigthat parsesCMakeLists.txtto find the realBINARY_NAME. As a result,appBinaryNamedefaults topubspec.name, causing broken paths if CMake defines a different name.%installscript attempts to symlink files using incorrect names, leading toFile not founderrors during the build or broken symlinks after installation.Proposed Solution
MakeRPMConfigto extendMakeLinuxPackageConfig. This inherits the correctappBinaryNamegetter.%installsection to create a symlink pointing to the real binary ($appBinaryName) but named after the package (%{name}).appBinaryName