Add flatpak target to ebuilder.config.mjs, update linux category metadata

[radmorecameron]

Pull Request Type

• Other - maintenance chore

Description

The main purpose for adding this to ebuilder.config.mjs is so I can create builds to easily test on my Steamdeck and postmarketOS phone.

This PR adds configuration necessary for Flatpak in ebuilder.config.mjs. I didn't add this to _scripts/build.mjs but it could potentially be useful for Flathub users (especially ones on immutable distros like the Steam Deck or Bazzite) to test specific PRs (we'd need to make special builds for them)

Testing

On a linux machine:

• Apply this patch:

index 1617f1ad5..dae9cb8ba 100644
--- a/_scripts/build.mjs
+++ b/_scripts/build.mjs
@@ -34,7 +34,7 @@ if (platform === 'darwin') {
     arch = Arch.armv7l
   }
 
-  targets = Platform.LINUX.createTarget(['deb', 'zip', '7z', 'rpm', 'AppImage', 'pacman'], arch)
+  targets = Platform.LINUX.createTarget(['flatpak'], arch)
 }
 
 const output = await build({ targets, config, publish: 'never' })

• Uncomment the flatpak section in ebuilder.config.mjs
• run pnpm run build.

I had an issue when I first ran at and was able to debug by patching @malept/flatpak-bundler with the changes in this PR: malept/flatpak-bundler#60

Essentially you'll need flathub setup, the runtimes installed and flatpak-builder installed

Desktop

• OS: Fedora Linux
• OS Version: 44
• FreeTube version: latest nightly

[absidue]

Not sure why we would even want this, as the flatpak's that electron-builder creates are documented to be different than what would be published on flathub. We will also not be able to use whatever is generated here to publish on flathub, we already have a special exception to be allowed to build the app itself here instead of on flathub's infra like the flathub rules say you are supposed to do (we can't because our builds require internet connectivity), if we don't even want to use the proper tools to create the flatpak, we might as well just go ahead and ask them to remove FreeTube from flathub instead of waiting for them to inevitably remove it for breaking lots of rules.

Currently electron-builder does not support publishing apps to Flatpak repositories like Flathub. Flatpak support in electron-builder is limited to generating single-file bundles which have limitations compared to apps installed from a repository.

https://www.electron.build/docs/flatpak/

single-file bundles don’t include dependencies or AppStream data

https://docs.flatpak.org/en/latest/single-file-bundles.html

I also mentioned in that past that I do not want the FreeTube nightlies to be available on flathub, for the same reason that we got rid of the dedicated nightly repository, the nightlies are pre-release testing versions, that are not supposed to be used by most users and the friction of having to be logged into GitHub and find the artefacts in the Actions tab, is thankfully enough friction to deter most users.

[efb4f5ff-1298-471a-8973-3d47447115dc]

I agree with Absidue's comment. I would like to see some more arguments for the benefits of including it in other builds. I've never seen users bring it up in this repo so i wonder if they really care

[radmorecameron]

I should have been more clear in the description, I wasn't planning to push the single file build to Flathub. It was more for me to test some changes using Flatpak on some of my devices where AppImage wouldn't work (ex: I want to test #9523 on some weirder devices before marking it as ready). Adding the flatpak to nightly (Not Flathub but our GitHub Actions nightlies like our other packages!) was a potential suggestion for the future if needed (but this PR didn't include it as I didn't feel it was necessary)

For including the Desktop and Metainfo here,

• For including it in other builds, (mainly for the desktop file) I have ideas on reading the desktop file in ebuilder.config.mjs and adding the translated comments to our desktop files (which has been brought up on this repo)

• I'd eventually like to have a pipeline to validate our appstream metainfo file (and if it's here and electron builder eventually allows us to easily add it to our builds, we might as well do it IMO)

For including appstream in our other Linux builds:

• I figure if it gets moved to our repository and electron builder lets us easily add it to our builds, we might as well add it to our current builds; it'd show more information about FreeTube when someone is looking at their installed apps.

[radmorecameron]

I updated the description of this PR, hopefully it's more clear now, I removed the part about metadata/desktop file because that's a future discussion.

[absidue]

I have to say I was more onboard with the idea of the metadata as that sounded like it would be useful, rather than providing unofficial flatpaks. If we were to merge this I would want to agree first that we will not be adding this to the nightly builds in this repo and add a code comment to the flatpak additions added by this pull request explaining that we will not provide support for flatpaks built this way and that it exists purely to help people create personal flatpak builds.

[absidue]

Probably best to leave the flatpak stuff commented out by default to reenforce the point, that it is completely unused for all of the official release and nightly builds.

[github-actions]

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[efb4f5ff-1298-471a-8973-3d47447115dc]

should this be the same as?
https://github.com/flathub/io.freetubeapp.FreeTube/pull/170/files#diff-b3a1c21ff901033cb7f4734a94954da241931549d94f6b27e30c5097803c6fc2R10

also are the keywords needed here? or does only category matter here?