Mention installation via flathub

[alexlarsson]

Hi, i just wanted to point out that I packaged betaflight-configurator for linux using flatpak, and it is now available on flathub: https://flathub.org/

(The actual packaging is done at https://github.com/flathub/io.github.betaflight.BetaflightConfigurator in case anyone is interested in helping out)

[mikeller]

Hi @alexlarsson. Thanks for your efforts. This seems to be working well (on Ubuntu 17.10 here). The binaries seem to be generated server-side for this. How does triggering a new build (i.e. for a new configurator release) work?

[alexlarsson]

A trigger causes a rebuild each time there is a new commit in the repo with the manifest. See https://github.com/flathub/flathub/wiki/Maintaining-an-application-on-flathub for details.

There is some more complexity for this as I have to run a script on the new packages-lock files to regenerate the list of npm does. I can write up the docs for that if someone else wants to take over the maintenance.

[mikeller]

@alexlarsson: Thanks for your explanation. I certainly see this as a valuable addition, since it makes installing the app on linux more convenient than downloading / unzipping the archive. As such, I am happy to add instructions for it to the installation instructions (that will have to be updated to cover the standalone installation first).

Is there anything that can be done in the betaflight-configurator repository to get around you having to run that script? If so (and if it doesn't break other stuff), it is worth doing in my opinion.

[alexlarsson]

There is no way to get out of having to run the script. It pre-parses the package lock file and generates download instructions to set up a pre-seeded npm cache dir so that the actual build can run with no network access.

However, what would be useful is if you could add the .desktop file and the .appdata file to the repo:

https://github.com/flathub/io.github.betaflight.BetaflightConfigurator/blob/master/io.github.betaflight.BetaflightConfigurator.appdata.xml

https://github.com/flathub/io.github.betaflight.BetaflightConfigurator/blob/master/io.github.betaflight.BetaflightConfigurator.desktop

Actually, you might want to change the Exec= line in the .desktop file as it now points to the "run.sh" wrapper script i have in the flatpak.

Also, I have to patch gulpfile.js to set an explicit NW version to avoid network access (https://github.com/flathub/io.github.betaflight.BetaflightConfigurator/blob/master/set-nw-version.patch). Maybe you could take a commandline argument for this or something like that?

[alexlarsson]

Also, note that the appdata file above is quite minimal. If you're interesting in fleshiing it out, here is the spec: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html and here is some examples https://fedoraproject.org/wiki/Packaging:AppData

[mikeller]

@alexlarsson: Thanks for the info. Have a look at betaflight/betaflight-configurator#833. Work is currently under way to make the configurator build as .deb packages. This includes .desktop files, so it might be possible to reuse these. In general, I'd be happy to add the files that are required for the flatpack release to the configurator repository (even if just to keep it all in one place).

[mikeller]

I think that hardcoding the NW version for all builds is a reasonable move in any case, since this will ensure more reproducible build results. @McGiverGim, @basdelfos, what's your thoughts?

[basdelfos]

Yes, hardcoding the NW version is a good idea. I was thinking about doing the same thing. My diskspace is filling up with all kinds of NW versions for various platforms (and count that 3 times for 3 NW apps). The version can be 'hardcoded' in the package.json file.

[McGiverGim]

Is the more reasonable way. We must update it with each version of the configurator, to be always with the latest version, but the generator must use the same version for everybody in a defined version. If something is wrong and a bug is found in this version on NW, we must release a new version of the configurator with the NW updated. Maybe we must do the same with all the dependencies of the package.json.

[mikeller]

I think the way it is done for the npm packages in package.json and package-lock.json is correct - it is the industry accepted way of fixing package versioning. #836 takes care of using a fixed version for the NW.js toolkit.

[McGiverGim]

Yes, what I say is that in the package.json we have "regular expressions", version "greater" than, "similar than", etc. This lets the library change from one user to another if a new version has been released.

Maybe is the only way to go, some of de dependencies have it's own dependencies and in this way we are more flexible.

[mikeller]

I think this is the best way to go - not so much to make us flexible, but because this is how the maintainers of npm packages expect it to be done. (Most of the dependencies were added to package.json with npm install <app> --save-dev.)

[stale[bot]]

This issue / pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

[zandorsp]

It's stuck now abandoned on very old version 10.1.0