Add flatpak build manifest and necessary extra data #1
Conversation
|
|
|
How do we handle release/nightly update channels? |
Flathub itself is mostly intended for stable releases, and this manifest is geared around that (cf. the x-checker-data segments looking for tagged releases in the shadps4 git repo). Flathub does have a beta channel that could be used for dev builds; the way this is handled is by adding a |
So if user want to use the beta channel they have to add the Flathub beta repo manually? |
Co-authored-by: Quang Ngô <[email protected]>
Yup, and install from the beta repo specifically either using the relevant control in their graphical package manager, or via |
net.shadps4.shadps4.metainfo.xml
Outdated
| <project_license translate="no">GPL-2.0</project_license> | ||
| <launchable type="desktop-id" translate="no">net.shadps4.shadps4.desktop</launchable> | ||
| <url type="homepage" translate="no">https://shadps4.net/</url> | ||
| <icon type="remote" width="256" height="256" translate="no">https://cdn.jsdelivr.net/gh/shadps4-emu/shadps4@main/src/images/net.shadps4.shadps4.svg</icon> |
There was a problem hiding this comment.
To avoid any frictions that block this PR from getting merged, I think you should update external links to point back to GH or preferably to official website. Then when everything is sorted out. You can make another PR to update for these links.
There was a problem hiding this comment.
The jsdelivr links are just CDN mirrors for Github; jsdelivr is a free CDN for open-source projects backed by a number of the major commercial orgs in the CDN space - so any changes to these files in the github repository will be automatically reflected in the jsdelivr CDN cache.
GitHub notably has a very short cache expiry header on its "raw" file links, so end-user browser caching is much less effective than on a regular CDN or even a static web server; additionally github's raw files are served with wrong content-type headers for various file types, which can cause browser compatibility issues.
jsdelivr is just a thin layer that, without requiring any explicit uploads or configuration, can just wrap around links to files on a number of supported open-source hosting sites (eg github, npm, wordpress etc) with a simple change to the URL and will mirror them to a CDN built on a number of different providers' infrastructure and forward the requests there.
net.shadps4.shadps4.yml
Outdated
| # don't include submodules, which shadps4 depends on (in the externals directory) | ||
| - type: git | ||
| url: https://github.com/shadps4-emu/shadPS4 | ||
| tag: v.0.4.0 |
There was a problem hiding this comment.
how does this work with the releases xml?
There was a problem hiding this comment.
They don't interact at all - the releases.xml is a manually maintained file and used mostly for information. For example, Flathub uses it to generate the "what's new in [version]" segment on its web listings for apps. As Flathub's main channel is intended for stable releases, their submission guidelines request that builds use release versions of each app.
The tag specified here is simply the git tag to be checked out on the repository after it's checked out, ie. the version of the code to be built - combined with the x-checker-data spec monitoring for new tags in the repository here, whenever a new tag matching the tag-pattern in the x-checker-data spec is pushed to this repository, Flathub's infra will pick this up and automatically create a PR in the flathub/net.shadps4.shadps4 repository to update the manifest to this new tag and kick off a test build. As long as new shadps4 releases are tagged in the repository with a tag matching the pattern, the Flathub build will only require merging an automatically-created PR to roll the update out there.
As for the releases.xml, I'm working on (but haven't finished) a GitHub Action that can be run when a new GitHub release is created to plug the information from the GH release into the .releases.xml (or the metainfo.xml if required) and update the release tag to a new commit with the updated file. Once I've finished and tested this I'll be happy to PR a workflow to automatically maintain the releases.xml file :)
|
The 6.8 KDE runtime was rebuilt on Friday so should now have libfmt:
|
net.shadps4.shadPS4.yml
Outdated
| sdk: org.kde.Sdk | ||
| command: shadps4 | ||
|
|
||
| # TODO: vvvvv These can go away once shadPS4 PRs 1494 and 1495 are merged vvvvv |
There was a problem hiding this comment.
this needs to be updated. im assuming the icon can be removed from this PR as well?
There was a problem hiding this comment.
v.0.4.0 doesn't have these icons yet :(
|
A bit nitpick but manifest file extension should be in full form |
net.shadps4.shadPS4.yml
Outdated
| # don't include submodules, which shadps4 depends on (in the externals directory) | ||
| - type: git | ||
| url: https://github.com/shadps4-emu/shadPS4 | ||
| tag: v.0.4.0 |
There was a problem hiding this comment.
I think we should follow RPCS3 and use main branch here?
There's some TODOs here - feedback on these would be good! Other than that, this should be fairly directly in a shape where it's submissible to Flathub :)