fix(linux): use FQDN naming for all Linux packaging types

[psyke83]

Normalize install files to use the FQDN naming scheme for all package types (native/AppImage/Flatpak) to allow XDG compliance.

• Use FQDN naming convention for icons.
• Use "app-FQDN" naming convention for unprivileged systemd service; fixes XDG Desktop Portal app_id detection.
• Restore privileged "sunshine-kms" service unit back to "sunshine" and restore as the default in documentation and via preset unit. The unprivileged service only needs XDG compliance.

Description

Screenshot

Issues Fixed or Closed

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[psyke83]

These changes are enough to fix XDG detection when streaming via Portal grab, but if we want more complete compliance, the real binary should probably be named "PROJECT_FQDN" as well. Should we change it or leave as-is? Detection works fine on Fedora 43 with the native package and these current changes.

[sonarqubecloud]

Quality Gate failed

Failed conditions
3 New issues
3 New Code Smells (required ≤ 0)
D Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[ReenigneArcher]

These changes are enough to fix XDG detection when streaming via Portal grab, but if we want more complete compliance, the real binary should probably be named "PROJECT_FQDN" as well. Should we change it or leave as-is? Detection works fine on Fedora 43 with the native package and these current changes.

I think we should change it. Maybe for this one we can create an alias in the post install scripts?

[psyke83]

These changes are enough to fix XDG detection when streaming via Portal grab, but if we want more complete compliance, the real binary should probably be named "PROJECT_FQDN" as well. Should we change it or leave as-is? Detection works fine on Fedora 43 with the native package and these current changes.

I think we should change it. Maybe for this one we can create an alias in the post install scripts?

I'm not sure what kind of alias you mean? XDG detects the app_id using multiple matching strategies, including the name of the executable via /proc/$(pidof sunshine)/exe. This would point to the real file and not a symlink. But it's already matching correctly without this change.

[ReenigneArcher]

I'm not sure what kind of alias you mean?

Disregard, for I was mistakenly thinking this PR was changing the binary name.

[psyke83]

I'm not sure what kind of alias you mean?

Disregard, for I was mistakenly thinking this PR was changing the binary name.

So we'll leave the binary name as-is? I think it's ok. Are you comfortable with the hardcoding of the FQDN in scripts, though? It would cause issues for forks that change to their own FQDN. Should I modify the cmake scripts to replace the strings in these files in the same way that the service files are processed?

[ReenigneArcher]

Are you comfortable with the hardcoding of the FQDN in scripts

Hardcoding is fine.

The configure files was not really meant to help forks anyway. It was more to have less places when an adjustment was made.