Best way to submit new app: sources or binary?

1

Hi, I am the author of the DOS Browser project.

This is a browser with hardware acceleration for DOS games, allowing you to play them much faster than in Chrome, for example.

I want to publish it on Flathub.I am new to Flathub, but I have already built a Flatpak for my app, and it works fine. Now, I am trying to figure out how to publish it correctly.

This browser is based on Electron (electron-forge) and speeds up emulation by running DOSBox and DOSBox-X natively.

I read the following in the documentation (Best Practices section):

Patches that add or remove application functionality, large and complicated patchsets, binary files, source code, or any additional tooling must not be in the submission.

However, when I looked at the PRs section, I noticed many submissions include binaries. Often, the submission is just a wrapper for a binary. So, is this “best practice” guideline strictly enforced, or is it acceptable to provide a wrapper for a binary?

Here are the options I am considering for publishing:

  1. Build everything from source
    This would require significant effort. I would need to create a Flatpak that builds DOSBox, DOSBox-X, and the Electron client app. It’s doable but is the most challenging option.
  2. Build the client app (Electron) from source and ship the DOSBox and DOSBox-X backends as binaries .
    This approach is much simpler. However, it makes using electron-forge somewhat pointless. Electron-forge handles building the Flatpak for me, but in this case, I would need to write my own build scripts. While this is acceptable, it adds complexity.
  3. Build everything on my side with electron-forge and provide a wrapper script for the binary
    This is the simplest approach, but I’m unsure if it’s acceptable.

Could you help me decide which option is better? Also, is it okay to publish such an app on Flathub? I don’t want to invest a lot of time in Option 1, only to have the submission rejected for other reasons.

Additionally, I have a question about the runtime: electron-forge builds against the old runtime (20.08). Is it valid to use this for submission?

–
Project refreneces:
emulation engine (I am an author): GitHub - caiiiycuk/js-dos: The best API for running dos programs in browser GPL-2.0. js-dos allows to run DOS/Win 9x program in browser, so the DOS Browser is made to accelerate such websites.
dos.zone - is a community driven library of DOS games which can be viewed by DOS Browser.
DOS Browser download page: Download | DOS games in browser (already have deb/rpm)

–
P.S. DOS Browser is a just browser + emulation layer, it does not break any legal rights. Currently it able to view only dos.zone website but soon it will support any site that based on actual js-dos library (working on it).

2

No, building from source is preferred if you can’t use binary packages.

Patches that add or remove application functionality, large and complicated patchsets, binary files, source code, or any additional tooling must not be in the submission.

This means “don’t git add a binary file and open a PR with that”, you are free to build from binary packages in the Flatpak manifest.

3

Why we usually want people to build from source, is that you also get ARM support then. So that’s something to consider.

I don’t think that would be a problem, but users might get warnings (in the cli) with that runtime.

4

Submissions using EOL runtimes aren’t accepted.

1 Like
5

Ohh, this means that Electron Forge is actually useless. Okay, then I can go with option 2, because building DOSBox or DOSBox-X is not trivial.

6

While redistributing the binaries would probably be the easiest way, you could base a source-build on existing manifests.

As far as I can tell, DOSBox-X is build from sources, if I read the manifest correctly.
You could take the modules there as a base for building it in your app.

I don’t know about electron-forge, but two things:
First, if it can build a Flatpak, shouldn’t the runtime version be a configurable value?

And second, more importantly, when submitting to Flathub, you submit a manifest which the Flathub CI builds. So you probably be best of to base the manifest on the Electron Base app.
And if you need to run electron-forge for some reason, it would run inside the environment defined by the manifest.

7

Wow, this is very helpful. I mean, yeah, I could probably build everything from source, but since I’m very new here, it seems like a difficult task to build SDL, SDL2, and an Electron app all together for Flatpak (it is easier to build each in isolated environment).

This is also why I’m using Electron Forge—it has a lot of builders, so you can build for many platforms like Windows, *Nix, macOS, etc. It can also build for Flatpak and Snap. However, I think the Flatpak builder is unmaintained and relatively outdated. I can set the runtime, but when the runtime is >20.08, Flatpak fails during the build process. Since I don’t know much about it, it’s hard to understand how to solve this issue. Additionally, the documentation for Electron Forge is very poor, so it’s probably better to avoid using it for Flatpak, at least for now, because it works well for other platforms.

So, can I start with option 2 and then migrate to option 1 later?

8

There are shared-modules for SDL at least GitHub - flathub/shared-modules: Common Flatpak modules that can be used as a git submodule

And you will want to use GitHub - flathub/org.electronjs.Electron2.BaseApp as it should make your life easier.

As far as I know, that builder wouldn’t even help you, as they build a flatpak and we don’t accept flatpaks, but only build manifests.

Yes, you’ll probably need Maintenance | Flathub Documentation then.
And maybe take inspiration from other electron apps, we have
GitHub - flathub/electron-sample-app: Sample application based on electron or GitHub - flathub/im.riot.Riot or GitHub - flathub/org.signal.Signal come to mind

9

Oh, I’m really frustrated. I’m trying to create an Electron Forge app but no luck, it should be a simple task but I’ve spent too much time on it…

I created an issue: Unable to build simple eletron-forge application using yarn / npm, failing on node-gyp · Issue #629 · flatpak/flatpak-builder · GitHub

10

From the practical perspective, it will be always easier to repackage a binary. I suggest you submit that for starters, and try to figure out if you can make it work from source with our offline build environment.

FTR im.riot.Riot and org.signal.Signal mentioned by razzee are also repackaging binaries.

11

Well, this is my submission Add zone.dos.Browser by caiiiycuk · Pull Request #6053 · flathub/flathub · GitHub