Integrate AUR package sunshine-git

[ReenigneArcher]

Description

• Add configurable PKGBUILD for AUR
• Add optdepends to PKGBUILD
• Build PKGBUILD file in docker container
• Create .SRCINFO file automatically
• Validate PKGBUILD file using namcap
• Use action to publish to AUR automatically sunshine-git

Screenshot

Issues Fixed or Closed

• Fixes Publish to AUR using aurpublish #39

Type of Change

• New feature (non-breaking change which adds functionality)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the docstring/documentation-blocks for new or existing methods/components

[stephensrmmartin]

@stephensrmmartin

I think these should be put into /usr/share/sunshine; or preferably assets should be in /usr/share/sunshine, and config should be in either /usr/lib/sunshine or /etc/sunshine/ (depending on whether the configs are used by default, or simply there as a prototype at runtime to be copied; i.e., if you are loading the config, then /etc; if you are copying it to XDG config, then /usr/lib/ would be a better bet for configs).
... rather than /usr/local. /usr/local shouldn't really be touched by packages (even AUR ones).

The location was chosen for all unix systems based off of this comment: #144 (comment)

Not saying it's correct, but there should be more discussion around the paths. One thing is for sure... I want all Linux packages that we are distributing to have the same paths (as much as possible).

Indeed - I think "True-to-form" Unix systems (freeBSD, Darwin/osx) treat /usr/local as 'the place to install anything that is not part of the official unix distribution's software suite'; i.e., all unsupported, 3rd-party apps. [Edit: This is not true of netBSD; netBSD uses /usr/local to mean what linux means: non-managed, system-local installs. /usr/pkg/ instead contains any software not part of the base install, but installed via a package management tool].

Linux's filesystem standard is different though, due to there being no "authoritative" base set of what defines a Linux system. systemd itself actually includes a manpage (man filesystems) on their fs standard, and the linux foundation has an hierarchy standard (man hier). In either case, /usr/local on linux is meant for system-specific, site-local installations, such that it's kept separate and untouched by any system or package manager updates.

Despite all the various distros, they all seem to agree that /usr/local is not something the package manager touches; it's pretty specific to system-local customizations (e.g., if I wanted to compile and install a modified version of VLC, separate from the package manager's version of VLC, then it would go in /usr/local).

It'd be 100% safe to say, that on OSX/freeBSD: /usr/local is a reasonable prefix; and that on any linux distro of even moderate interest, /usr/ would be the correct prefix.

Udev rules from packages should, from what I understand, go into /usr/lib/udev/rules.d/.
/etc/udev/rules.d is meant for overrides or custom configs by the user.

This seems reasonable. The issue will be ensuring the existing file get's removed.

The existing files will be removed, so long as they are tracked by the package manager, and so long as the package is not specifically configured to preserve those files on removal.

[ReenigneArcher]

@stephensrmmartin thank you, that explanation makes sense.

Please let me know if you agree or disagree with this by placing a 👍 or 👎

os	binary	configs	assets	udev rules
Linux	/usr/bin/sunshine	/etc/sunshine	/usr/share/sunshine	/usr/lib/udev/rules.d
MacOS	/usr/local/bin/sunshine	/usr/local/etc/sunshine/config	/usr/local/etc/sunshine/assets	n/a ?

At the moment I believe the configs are used in the same location you that they are installed to... unless the user specifies a different config and apps.json path... then the default ones are copied over.

In this case, I am hoping the definitions on Linux will be acceptable for any distro (Debian, Red Hat, Arch, etc.), and MacOS according to your comment would likely be the same for freeBSD if we ever create a package for that.

[stephensrmmartin]

The linux and macos paths look good to me. My only remaining question is whether the /etc/sunshine config directory is there to have configs that are actually loaded, or if it has configs that are example configs which are copied into ~/.config/sunshine/ (or, generally, XDG_CONFIG_HOME/sunshine). If it is a 'prototypical' config that is copied when the user runs the sunshine user service, then it should belong in either /usr/lib/sunshine or /usr/share/sunshine (the choice is unclear, I've seen it both ways). But this is such minutiae.

Regardless though, the choice of assets, udev rules, binary, and configs are acceptable regardless of the distro at this point I believe. I don't even foresee anyone quabbling about a prototypical config being put into /etc/ (I'm not sure there's a particular 'rule', per se, about prototype configs belonging in /etc or elsewhere, it just seems like they tend to wind up in /usr/share or /usr/lib).

The macos paths should be similar to freeBSD I believe. Netbsd has different paths; openbsd may have different paths too (I'm not as familiar with these two). I would not personally worry about these latter cases. The number of people who want to run sunshine on netbsd or openbsd would surely be so vanishingly small, that if they truly wanted to port it, they can feel free to submit a PR.

[ReenigneArcher]

My only remaining question is whether the /etc/sunshine config directory is there to have configs that are actually loaded, or if it has configs that are example configs which are copied into ~/.config/sunshine/ (or, generally, XDG_CONFIG_HOME/sunshine)

This is how I believe it works.

./sunshine -> uses sunshine.conf and apps.json as they exist
./sunshine ~/sunshine.conf will copy the existing config to the destination (or maybe it just writes a brand new config)

I've had a lot of issues with this, and ideally these files don't even need to exist, and should be baked into the source code and created when needed.

The default config is blank anyway, and always has been (previously everything was commented out and just served as documentation)... I have since moved the documentation to read the docs.

I just don't have the time to dig into the source code to change this behavior.

The one reason I wouldn't write the files to the home directory is that sunshine can really only be run from one user simultaneously, and probably should only have one config.

[stephensrmmartin]

My only remaining question is whether the /etc/sunshine config directory is there to have configs that are actually loaded, or if it has configs that are example configs which are copied into ~/.config/sunshine/ (or, generally, XDG_CONFIG_HOME/sunshine)

This is how I believe it works.

./sunshine -> uses sunshine.conf and apps.json as they exist ./sunshine ~/sunshine.conf will copy the existing config to the destination (or maybe it just writes a brand new config)

I've had a lot of issues with this, and ideally these files don't even need to exist, and should be baked into the source code and created when needed.

The default config is blank anyway, and always has been (previously everything was commented out and just served as documentation)... I have since moved the documentation to read the docs.

I just don't have the time to dig into the source code to change this behavior.

The one reason I wouldn't write the files to the home directory is that sunshine can really only be run from one user simultaneously, and probably should only have one config.

Alright; well if /etc has a functional config, then keep the config in there.

As for per-user config, I believe it's fairly standard practice to have a 'default' config copied over to $XDG_CONFIG_HOME/sunshine/sunshine.conf if it doesn't exist, and if it's run as a user rather than a system account.

Personally, I think it makes sense to have per-user configs, especially if we are typically running it as a systemd user service (e.g., systemctl --user start sunshine). That behavior doesn't strike me as odd at all.

Having a 'default' config consist of nothing but commented-out, default options is also pretty common as far as I know.

[istori1]

I have been a bit confused on this given Sunshine already saves some configuration into the users home.

Since it is running as a user service, it will be standard practice to place the config into $HOME/.config/sunshine

I believe @ReenigneArcher wants a system configuration, in which case I would suggest to use /var/lib/sunshine for that, and making the sunshine sub-folder only accessible by the input group.

Since there is already data stored on $HOME/.config/sunshine we should be either saving all the configuration there or changing the Sunshine code to do all config data in /var/lib/sunshine for a system wide writable configuration.

Ideally there should be a read only default config somewhere in /etc that gets copied to $HOME/.config/sunshine and then the Web UI edits that user configuration.

[ReenigneArcher]

@istori1 I don't want a system configuration necessarily, although that does make sense to me since running more than one instance of Sunshine will be problematic... likely the ports will already be in use, most moonlight clients do not allow a custom port range, and of course hardware limitations. With that said, I'm okay with it using the home directory.

It's possible I may have broke something when refactoring for the packaging updates previously... this was a massive PR. Do you know if the config or apps files were saved there in previous versions?

[stephensrmmartin]

@istori1 I don't want a system configuration necessarily, although that does make sense to me since running more than one instance of Sunshine will be problematic... likely the ports will already be in use, most moonlight clients do not allow a custom port range, and of course hardware limitations. With that said, I'm okay with it using the home directory.

It's possible I may have broke something when refactoring for the packaging updates previously... this was a massive PR. Do you know if the config or apps files were saved there in previous versions?

I have those files too, but the aur package currently has a service file that literally does that copy if the configs aren't already in the config directory. As in, the user service file checks for XDG_CONFIG_HOME/sunshine and if it doesn't exist, copies files from the packaged config directory.

I suspect that a system (or system user) running sunshine wouldn't even work, no? I haven't tried, but I imagine there'd be inherent limitations to what can be streamed depending on which X display is open, or which Wayland session is active. It's not like a vnc server is running. It's ffmpeg recording an active session, no?

[ReenigneArcher]

I have those files too, but the aur package currently has a service file that literally does that copy if the configs aren't already in the config directory. As in, the user service file checks for XDG_CONFIG_HOME/sunshine and if it doesn't exist, copies files from the packaged config directory.

I see some issues with this approach: https://aur.archlinux.org/cgit/aur.git/tree/systemd-user-config.patch?h=sunshine#n10

• It's copying the entire assets directory (shaders, web, configs, etc.)... that's a complete waste
• I think the copied files have the original permissions, so they are still read only
• It's only using the copied sunshine.conf, not the apps.json, and still points to the default apps.json (read only)
• It's unnecessary as sunshine will already copy the default sunshine.conf if you start sunshine like this sunshine <preferered conf file>

[stephensrmmartin]

I have those files too, but the aur package currently has a service file that literally does that copy if the configs aren't already in the config directory. As in, the user service file checks for XDG_CONFIG_HOME/sunshine and if it doesn't exist, copies files from the packaged config directory.

I see some issues with this approach: https://aur.archlinux.org/cgit/aur.git/tree/systemd-user-config.patch?h=sunshine#n10

* It's copying the entire assets directory (shaders, web, configs, etc.)... that's a complete waste

* I think the copied files have the original permissions, so they are still read only

* It's only using the copied `sunshine.conf`, not the `apps.json`, and still points to the default `apps.json` (read only)

* It's unnecessary as sunshine will already copy the default `sunshine.conf` if you start sunshine like this `sunshine <preferered conf file>`

I totally agree; it's definitely a hack (I'm not sure who originated that hack; if it was the AUR submitter/maintainer, or upstream at some point).
The service file shouldn't do any copying. That should be up to sunshine itself, based on whether you have a config already.

I imagine the best solution would be to 1) Use /etc/sunshine/* if $XDG_CONFIG_HOME/sunshine/* is not populated and 2) When a user changes a setting, to save the config to $XDG_CONFIG_HOME/sunshine/; 3) When $XDG_CONFIG_HOME/sunshine/sunshine.conf exists, use it by default and unless they explicitly specify another config via command line.

[ReenigneArcher]

On a side note... anyone know how long it takes arch to respond to requests? I know they have a lot, but I would expected this to get a response by now?

https://aur.archlinux.org/packages/sunshine

https://lists.archlinux.org/pipermail/aur-requests/2022-June/073138.html
https://lists.archlinux.org/pipermail/aur-requests/2022-June/073186.html

[ReenigneArcher]

Not sure how to make the build have different prefixes... It didn't like this...

        -D CMAKE_INSTALL_PREFIX="/" \
        -D SUNSHINE_ASSETS_DIR="usr/share/sunshine" \
        -D SUNSHINE_CONFIG_DIR="etc/sunshine" \

https://github.com/SunshineStream/Sunshine/runs/7035419321?check_suite_focus=true#step:7:990

So going to use this until the paths can be addressed better in a separate PR.

        -D CMAKE_INSTALL_PREFIX="/usr" \
        -D SUNSHINE_ASSETS_DIR="share/sunshine/assets" \
        -D SUNSHINE_CONFIG_DIR="share/sunshine/config" \

[ReenigneArcher]

v2.3.0 has been released now

[ReenigneArcher]

Perhaps I'm too impatient, but I'm kind of losing faith that the aur people will orphan the repo for us.

What option do you guys want.

1. Use sunshine-git (this will be indicated in our docs that this is the official one, and the third party one will remain how it is in the docs)
2. Create a new repo sunshinestream-sunshine

Let me know.

[stephensrmmartin]

Does this automated version push to aur on every master commit? Or is it only after a git release?

[ReenigneArcher]

Does this automated version push to aur on every master commit? Or is it only after a git release?

Every push to master, which will be when we decide to make a release as we push everything into nightly first.

[stephensrmmartin]

Does this automated version push to aur on every master commit? Or is it only after a git release?

Every push to master, which will be when we decide to make a release as we push everything into nightly first.

Then sunshine-git is fine to use.

I think other aur packages do this too. There's pkg, pkg-git, pkg-nightly-git, etc. Even if release coincides with master commits, it's appropriate to use -git. I don't think -git necessarily requires that it's tracking every commit ever pushed into a project at any given time. It tends to mean the master branch of the upstream repo, no matter what that project's master policy is.
If people want a truly bleeding edge version, they're free to switch the branch in the pkgbuild themselves.

[ReenigneArcher]

I think other aur packages do this too. There's pkg, pkg-git, pkg-nightly-git, etc. Even if release coincides with master commits, it's appropriate to use -git. I don't think -git necessarily requires that it's tracking every commit ever pushed into a project at any given time. It tends to mean the master branch of the upstream repo, no matter what that project's master policy is.
If people want a truly bleeding edge version, they're free to switch the branch in the pkgbuild themselves.

I would agree with that based on my research so far, although some didn't agree in the discord, haha.

My understanding is that -git strictly indicates that it's building from a git repo. We also will have the PKGBUILD as an artifact on CI workflow runs if users want to download from there.

[ReenigneArcher]

Unless there are any objections, this will be merged soon... Following the next push to master sunshine-git will be updated automatically.

[csolisr]

Pinging @ReenigneArcher to inform that the main AUR package has been orphaned and ready for takeover. https://aur.archlinux.org/packages/sunshine

[ReenigneArcher]

Thanks. I've adopted it.