devilutionX
devilutionX copied to clipboard
To-do list before submission to Flathub
- [x] Releases need to provide fully vendored source tarball. Flathub does provide dependencies via shared-modules, but they don't have any that are needed for this project. Hell, they don't even have SDL2, only SDL1; Solved via https://github.com/diasurgical/devilutionX/pull/4473
- [x] Flatpak demands that resource files (icons, metadata,
.desktop
files) are renamed to app ID.devilutionx.desktop
is renamed viarename-desktop
, need to figure out how to rename icons and Hellfire.desktop
file. See here: https://github.com/flatpak/flatpak/issues/750; Solved via https://github.com/diasurgical/devilutionX/pull/4468/commits/c2698f8a3588b3da2f5964b9de6844c16018e75a and https://github.com/diasurgical/devilutionX/pull/4468/commits/b51dee16c0638226bb00055621ec09d3ce48dbaf - [x] Build probably creates unnecessary files, this is handled through cleanup section of manifest. Need to figure out what needs to be cleaned up; Nothing to clean up, props to @AJenbo, @glebm and @StephenCWills who worked on CMake install logic
- [x] Copy
devilutionx.mpq
toXDG_DATA_HOME/diagurgical/devilution
at install or run time; No need to copy, fixed by https://github.com/diasurgical/devilutionX/pull/5306 - [ ] Import dialogue to avoid manually copying MPQs to sandbox. See https://github.com/diasurgical/devilutionX/issues/4470
- [ ] Add Discord integration for x86/64 (?). Discord SDK was added via https://github.com/diasurgical/devilutionX/pull/4430, but flatpak-builder fails to find it when building with
-DDISCORD_INTEGRATION=ON
. IMO, this shouldn't be a priority for first release on Flathub - [x] Add Appstream metadata file, handle its installation to standard location via CMake. Metadata format described here: https://www.freedesktop.org/software/appstream/docs/; Flatpak requirements for metadata here: https://docs.flatpak.org/en/latest/conventions.html#appdata-files; https://github.com/diasurgical/devilutionX/pull/4497
Bump. 12 months later. I suggest the remaining two items (MPQ import dialog) and Discord integration be removed as blockers for Flathub submission.
Not sure how others feel, but I'm ok with manually importing game files - other engines needing retail game assets provide instructions on how to extract the files and where to put them. That seems good enough for starters.
Also don't need Discord integration to play a game.
Not sure how others feel, but I'm ok with manually importing game files - other engines needing retail game assets provide instructions on how to extract the files and where to put them. That seems good enough for starters.
According to #4470 , this is a requirement for submission 🤷🏽♂️
Sorry for abandoning this for so long, partially this was because of power outages in Ukraine over autumn 2022 - winter 2023, but mostly due to my lack of know-how
After thinking about it, #4470 could be excluded as a requirement. It would be good to have, but I know zero C/C++ to implement it and other devs are lukewarm on it, so I won't hold my breath
Now that 1.5.0 was released, I plan to see it submitted and (hopefully) released on Flathub soon™
Not sure how others feel, but I'm ok with manually importing game files - other engines needing retail game assets provide instructions on how to extract the files and where to put them. That seems good enough for starters.
According to #4470 , this is a requirement for submission 🤷🏽♂️
A requirement for this project, or a requirement of Flathub? The GZDoom Flatpak, for example, has instructions that say "Copy any commercial iwad into the folder" where folder is a path in the sandbox.
That's what I was thinking about as a way to unblock Flathub submission, at least in the short term until a user-friendly dialog can be created.
Now that 1.5.0 was released, I plan to see it submitted and (hopefully) released on Flathub soon™
Yeah, that's what caused me to take a look at the project and then come from out of nowhere to make a comment. A flatpak version makes it much easier to integrate a non-steam game into the Steam UI on the Steamdeck, for example.
A requirement for this project, or a requirement of Flathub? The GZDoom Flatpak, for example, has instructions that say "Copy any commercial iwad into the folder" where folder is a path in the sandbox.
No idea, I'm just restating what the issue said:
There are some user-friendly compromises that could make this less painful whilst still respecting the sandbox concept (I like flatpak for games precisely because they can be isolated from the rest of the homedir where they have no business messing around).
One is to grant read-only access to the flatpak to a standard XDG compliant location like ~/.local/share/devilutionx/foldername and instruct users to put the game files there. Then there is no need for users to mess about in ~/.var/path/to/sandbox, and their game files are left alone after an uninstall.
I'm not at all familiar with flatpak creation, but in Flatseal (a tool to manage installed flatpak settings), access to non-sandbox folders is specified in an "other files" section, and can be specified like "xdg-data/path:ro". I presume that notation is used when creating flatpaks as well.
other devs are lukewarm on it, so I won't hold my breath
Implementing HTTPS, and GUI in a cross platform system isn't a whole lot of fun :) Just doing it for Android was enough for me. And like I mentioned that one still feels lacking (no copy button, no progress).
A flatpak version makes it much easier to integrate a non-steam game into the Steam UI on the Steamdeck, for example.
Is it really that different from AppImage?
One is to grant read-only access to the flatpak to a standard XDG compliant location like ~/.local/share/devilutionx/foldername
Sounds ideal, that's how it works with all supported methods. Well .local/share/diasurgical/devilution/
but I'm assuming it's what you meant.
A flatpak version makes it much easier to integrate a non-steam game into the Steam UI on the Steamdeck, for example.
Is it really that different from AppImage?
No, probably not. I just happened to settle on Flatpak on my personal desktop (Arch, btw), so that works for me. And on the Steamdeck, flatpak is the preferred way to install applications in Desktop mode, integrated into the package manager (Discover) so it's just easier. AppImage for those who prefer it is fine with me.
One is to grant read-only access to the flatpak to a standard XDG compliant location like ~/.local/share/devilutionx/foldername
Sounds ideal, that's how it works with all supported methods. Well
.local/share/diasurgical/devilution/
but I'm assuming it's what you meant.
Yes, that. Sorry for the guess - haven't installed DevilutionX yet (hoping for flatpak, LOL) so didn't know the exact path.
A flatpak version makes it much easier to integrate a non-steam game into the Steam UI on the Steamdeck, for example.
Is it really that different from AppImage?
No, probably not. I just happened to settle on Flatpak on my personal desktop (Arch, btw), so that works for me. And on the Steamdeck, flatpak is the preferred way to install applications in Desktop mode, integrated into the package manager (Discover) so it's just easier. AppImage for those who prefer it is fine with me.
The thing is that we already distribute a AppImage, deb, rpm, opk, and raw package for Linux users to pick from. Flatpack is yet another one and apparently it has a whole extra set of requirements that we need to maintain.
Yeah, packaging and application distribution on Linux is a challenge - don't forget snaps on Ubuntu. :-)
The question boils down to user experience, I guess. Anecdotally speaking, the uptake of Flatpak as a format currently seems to be quite strong. From a user perspective, it's a good way to get an experience similar to the 'native' package manager in a distribution-independent way and the tooling is getting pretty good. It also works well with systems that use immutable storage such as Steamdeck (or Fedora Silverblue, Endless OS etc). which are gaining some traction as well. The user experience generally seems to be pretty good from what I hear and read. So maybe not just Yet Another Packaging Format, or at least one that has enough user support to be worth providing.
Not sure why AppImage suddenly came up as a subject of conversation, to be honest. This issue is about submission to Flathub so the ship has already sailed?
Message ID: @.***>
don't forget snaps on Ubuntu. :-)
There is a draft for that also :roll_eyes:
Anecdotally speaking, the uptake of Flatpak as a format currently seems to be quite strong
I have never encountered it for anything that I had a need to install, it seams to normally be AppImage that is used from where I am.
Not sure why AppImage suddenly came up as a subject of conversation, to be honest. This issue is about submission to Flathub so the ship has already sailed?
Cause we need to first workout Flatpack before we can submit it to Flathub. And it's another things for me to test and verify during a release.
I'm not saying not to add it, but I really do wish I didn't have to deal with any of this. There are still users stuck on outdated versions because they got it via PPA or Snap which where not maintained. And I just don't have the time to resolve it atm.
App submitted to Flathub https://github.com/flathub/flathub/pull/4331 Will close if/when submission is accepted
• tag-invalid : <project_license> is not valid [LicenseRef=https://github.com/diasurgical/devilutionX/blob/master/LICENSE.md]SPDX ID 'LicenseRef=https://github.com/diasurgical/devilutionX/blob/master/LICENSE.md' unknown
• tag-missing : <content_rating> required [use https://odrs.gnome.org/oars]
• tag-missing : <release> required
• tag-missing : <url> is not present
You might have to register the license here: https://github.com/spdx/license-list-XML
Oh, your solution in #6245 should also work
Flathub have accepted our application! https://flathub.org/apps/org.diasurgical.DevilutionX
Thanks for the effort, sounds like this is helpful for Steam Deck users
That was the primary motivation to get this done