Questions about distributing applications

[takluyver]

This probably overlaps with issues like #12 #13 #15, but I hope it's useful to you if I highlight what questions I feel unsure about after reading the docs:

• How exactly do I do the GPG signing? I've muddled through something that seems to work, but I'm not sure that I've done it right (and I'm already starting to forget what I did).
• How do I distribute the public key for users to check with? I've found that I can put it in the .flatpakrepo file as one enormous line, but that file is currently on the same domain as the repo it's using, so anyone who could replace the packages could also replace the key. And what if you add a remote without using a .flatpakrepo file?
• Should I worry about signing? If the repo is served with HTTPS anyway, could I skip signing and just tell users to set it up with --no-gpg-verify?
• Do you expect that application developers will normally host their own Flatpak repo, or submit packages to a centralised 'app store' repo? In the latter case, many of my other questions go away, but it probably adds some others.
• How would I manage releases of my application? I think this particularly relates to No instructions for how to distribute multiple versions of an app #13 and Document how best to manage a repository #15.
• If I rebuild the same application into the same repo, is it adding data or replacing it? Is it sustainable to build every commit into the same repo, or will it grow indefinitely? Are there cleanup mechanisms to run?
• The notes on hosting a repo say that "it is important to enable HTTP keep-alive on the web server." If I put the repo on Github pages, where I'm not managing the server, how can I check if this is enabled? Is the load pattern of hosting a repo going to annoy Github?

I hope this isn't too pestering - the docs overall are great, and I've been able to get a long way with them. Thanks!

Since you suggested making a base app, I've made three different base apps with pygame installed on different versions of Python. I've also made a crude tool to conveniently build flatpaks of pygame games, which is described here: https://github.com/takluyver/pygame-flatpak-test#readme

[alexlarsson]

I wrote a blog post about this: https://blogs.gnome.org/alexl/2017/02/10/maintaining-a-flatpak-repository/

Some other remarks:

• GPG signing is important to the end-user because it gives a point of trust that the sysadmin can set up. In other words, if you configure a system-wide (not per user) remote with a trusted GPG key in the system then you can allow wheel users to install things from it without the root password. This is not possible for remotes without gpg key.
• You can distribute the flatpakref or gpg key however you want (presumably in a way people can trust it, say on a TLS webserver, or maybe even on a keysigning party or whatever). If you're not using a flatpakref you need to specify --gpg-import=FILE to remote-add or remote-modify.
• We do want to have a public shared store for flatpak applications, to make it easier to distribute and find applications. However, at the same time, allowing a free echosystem where anyone can run their own repo with full autonomy and still 100% feature-complete is important too.
• Without keep-alive you will do a lot of separate requests, which can be very slow. However, if you use static deltas then this is less of a problem, as the number of files (and thus requests) will be few.
• Rebuilding an app will build a new copy of it and store both. However, any identical files will automatically be shared. flatpak-build-update --prune-depth=DEPTH can be used to drop old commits.

[takluyver]

Thanks for those answers, and I'll read through the blog post soon. :-)

[allanday]

I've recently made some improvements to the docs, which means that they address most of the questions here. The outstanding issues are things like #13 and #15, but they're covered by other issues already.