Gnome Flatpak

[ghost]

Since everyone seems to be listing Linux distribution tools, I'll add gnome flatpak to the list as well:

http://flatpak.org/

[develar]

Do you like flatpack or just report issue ;)?

[ghost]

AppImage, Flatpak and Snappy Apps are the 3 modern solutions at the moment. That's why I created the issue :-)

[develar]

Moved to backlog to keep issue list clear.

[develar]

AppImage #504 supported.

[grafenhofer]

Flatpak is taking up in usage recently. It supports some features missing from appimage (support for automatic updates e.g. via proper integration in gnome software, KDE support seems to be coming,...). It could be time to reconsider the "backlog" tag.

[prcastro]

I agree. Flatpak is becoming the standard not only in GNOME, but within KDE and probably ElementaryOS environments. Seems also to be a non-centralized way to keep applications reproducible and sandboxed, and seems way more secure than the alternatives. The number of contributors is also bigger than AppImage and Snap. GNOME Apps, Spotify, LibreOffice, Skype and Telegram already have Flatpak builds.

[black-snow]

Anyone willing to tackle this? We have deb, rpm, AppImage and Snappy it would be a shame to not have flatpak as well.

[prcastro]

Maybe these links are of interest:

https://github.com/endlessm/electron-flatpak-base-app
http://blog.manuq.com.ar/posts/building-electron-apps-offline-for-flathub/

[develar]

Sorry, moved to backlog for now.

[lbssousa]

Flatpak is the last missing piece for electron-builder to become a trully complete tool for packaging Electron apps. Is it too hard to port electron-forge Flatpak implementation to electron-builder?

[vially]

There is a preliminary pull-request at #5711 which should make it possible to build *.flatpak bundles. In case anyone is feeling adventurous and is willing to give it a try, the early feedback would be greatly appreciated and it would help in ironing out the potential issues faster.

However, as others have already mentioned in this thread, for Flatpak it would make a lot of sense to expose the functionality to publish the app to a repository (e.g.: Flathub) but that is not part of this pull-request. That's partly because sometimes it's better to do things incrementally, but in this case it's also because it wasn't entirely clear to me how that should work.

So if anyone has some input on this it I might take a stab at it in the future. In particular, it would help a lot if it was clear what the input and output of such a feature would be (while keeping in mind the constraints of the Flathub App Submission process).

[rathboma]

@vially You are amazing! I think everyone would be happy to see your PR merged, even if flathub submission requires another PR.

[mmaietta]

PR Merged. Closing this issue.
Any future improvements/features, such as Flathub, should probably be tracked in a new ticket.

@develar can you please run a full release cut? I think 22.10 has enough feature introductions that we should publish as the latest npm version.

[vially]

I think it may be worth pointing out that this should be considered experimental for now.

I'm all for getting this out as soon as possible. But considering that I'm not very familiar with the electron-builder code base and since this hasn't received enough testing yet, it may be more prudent to change the Flatpak target to be disabled by default in the first release.

This way the early adopters can still manually enable it in their apps (which will help with ironing out the initial bugs) while keeping everyone else unaffected.

One big downside of Flatpak being enabled by default is the build-time dependency on flatpak-builder. This is a significant breaking change that needs to be documented properly because it has the potential to be very disruptive to the users of electron-builder who may or may not have flatpak-builder installed on their build machine (e.g.: dev machine or CI).

[mmaietta]

Certainly should be considered experimental and we'll need to get those docs working too

I'll open a PR to remove it from the default target list. I missed that.

[johannesjo]

Thank you very much @vially !!

Does anybody know if there is already an issue that tracks a more convenient way to publish to flathub? I don't know much about all the technical requirements for this, but a lot of my users have been wanting this for a long time.

Specifying flatpak as a target still doesn't work for the latest version of electron-builder. (seems like I need to install flatpak on my system for this to work, which makes sense).

[mmaietta]

There's currently no way to publish to flathub, but that would be a great integration to have. I'd be happy to advise if you are willing to contribute!
Here's a sample PR for Bitbucket publish and autoupdating #6228
Setting up a local dev environment is fairly simple as well: https://github.com/electron-userland/electron-builder/blob/master/CONTRIBUTING.md#to-setup-a-local-dev-environment

[gasinvein]

@johannesjo Making use of the recently-added flatpak support in electron-builder to publish on Flathub would require Flathub to accept binary uploads, what it currently doesn't allow. So, this is a more general issue than just about Electron. See flathub/flathub#2320 for a discussion about largely the same problem.
In the meantime, did you consider producing a flatpak as part of your CI pipeline without publishing it on Flathub?

[patriziobruno]

@johannesjo Making use of the recently-added flatpak support in electron-builder to publish on Flathub would require Flathub to accept binary uploads, what it currently doesn't allow. So, this is a more general issue than just about Electron. See flathub/flathub#2320 for a discussion about largely the same problem.
In the meantime, did you consider producing a flatpak as part of your CI pipeline without publishing it on Flathub?

Flatpak was initially designed to be published using repositories, not bundle files. Bundle support has been added later, but it lacks all the advantages of having a repository: live updates, delta updates, and dependencies decoupling. Flathub is just one repository, if one doesn't want to use it, they can set one's up or publish to some other repository. Publishing flatpak bundles doesn't really work.

[johannesjo]

@gasinvein & @patriziobruno thank you very much for the explanations! Much appreciated! Probably makes sense to try to solve this via github actions in my case then. You don't happen to know a github actions example for an electron app by any chance?

[TheEvilSkeleton]

@johannesjo I'm going to assume that you will need to submit an MR to include the Electron BaseApp under here https://github.com/bilelmoussaoui/flatpak-github-actions/blob/47e4de41f760530ebad88296894877f2d2cab0aa/.github/workflows/docker.yml#L15, since flatpak-github-actions doesn't include it.

[gasinvein]

@patriziobruno That is true, bundles aren't very user-friendly, but I guess a flatpak bundle is better than no flatpak at all?

@johannesjo I'm not very familiar with electron, but I guess you'll need fairly recent electron-builder first? The version super-productivity uses doesn't have flatpak target support. Other than this, I guess it shouldn't need much changes other than adding flatpak to target list and installing flatpak (and probably flatpak-builder) on the builder machine.

@TheEvilSkeleton No, this action is for a different workflow, when electron-builder is running inside flatpak-builder sandbox, see this comment.

[TheEvilSkeleton]

Ah, my bad.

[patriziobruno]

@patriziobruno That is true, bundles aren't very user-friendly, but I guess a flatpak bundle is better than no flatpak at all?

@johannesjo I'm not very familiar with electron, but I guess you'll need fairly recent electron-builder first? The version super-productivity uses doesn't have flatpak target support. Other than this, I guess it shouldn't need much changes other than adding flatpak to target list and installing flatpak (and probably flatpak-builder) on the builder machine.

@TheEvilSkeleton No, this action is for a different workflow, when electron-builder is running inside flatpak-builder sandbox, see this comment.

@gasinvein it's better to have flatpak bundles as a stepping stone to a flatpak repository. The discussion here and the resulting flatpak bundle implementation are priceless, but I hope they're not the end goal.

[vially]

There's been some discussion lately about the sustainability of open-source which reminded me of this issue (because it has a bounty attached to it).

I've been considering claiming that bounty for a while now, but since the current Flatpak bundle support (#5711) is, at best, a partial solution, I think it might be better to transfer the bounty (either fully or partially) to a new issue that tracks "publishing Flatpaks to a repository" instead.

Therefore, my suggestion for everyone who contributed to the bounty (@ignapk, @dteare, @simonxciv and @patriziobruno) would be to decide whether they want to:

• a) transfer it to a different issue that better tracks their use-case/feature request
  You might have to check what is the GitPay policy on these things or if they are even possible (/cc @alexanmtz).

• b) keep the bounty as is (in which case I'll claim it as part of this issue)

So just to make it absolutely clear, I'm still planning to claim the bounty attached to this issue, but only after everyone who contributed to the bounty has had some time to decide what they want to do about it.

Of course, everyone should feel free to suggest alternative solutions for this.

I would like to mention that, at least for me, it's a lot more important to get some closure and clarification on the scope of this issue than the bounty itself. If that means, for example, reopening this issue and defining its scope as "Publish Flatpaks to Flathub", that's a perfectly reasonable approach for me.

Offtopic discussion about bug bounty platforms

This is slightly offtopic, but I think these bug bounty platforms work great when both the scope and the solution are somewhat clear. However, there are various challenges involved when:

• the scope is not clear enough
• different sponsors have different (or even conflicting) requirements
• the solution is incomplete and/or implemented by multiple contributors
• etc

These are tough problems to solve and I'm not sure how they can be solved. But I think it's important to solve them if we want the bug bounty programs to succeed.

[puyoxyz]

so... is there an issue i can follow for flathub support ?

[mmaietta]

You can create one to encourage someone from the community to build support for a Flathub Publisher. I'm happy to review any code and provide examples of previously written publishers

[cbartondock]

Having some docs would really improve the situation. I feel like at the moment it's unclear if this works for all electron applications, or just some of them. It's also unclear to me which flat-pak options get exposed (all of module's sub-options for example?).

[Danik1601]

@cbartondock, someone made the documentations which was added in the latest pre-release

[soredake]

#7154