Flatpak Binary Helpers

[grhitch]

Adding ;bin to the end of the merge-dirs line means that links are automatically created allowing plugins to find their binary helpers. See for example oesENC where I created this issue bdbcat/oesenc_pi#92 (comment).
I accept that there may be other ways to solve this problem, but this does seem to work OK. With this small change in place I made a flatpak for oernc that also behaves properly.
Greg

[leamas]

Hi!

Sorry for late reply.

First: leamas/OpenCPN is just a playground thing right now (besides the wiki). See it as place where I develop my own PRs now and then, nothing more. The correct way to update for example the flatpak packaging is to make a PR against OpenCPN/OpenCPN.

Secondly: Unfortunately, all of the instructions I have left around are not updated "blushes". So: which instructions did you follow when yoy ran into the problem described in bdbcat/oesenc_pi#92?

[grhitch]

Hi Alec,
I wasn't sure where to post the PR and chose this fork as you seem to be doing a lot of the heavy lifting on the flatpak packaging. I am happy to create a new PR on OpenCPN/OpenCPN, but would like to be sure that it is an approach that you support.

As to which instructions I used, I started with #OpenCPN#1457 (comment). But I also looked at every set of instructions that you have 'left around'. In the end, I have installed from the beta repository and built and installed from leamas/OpenCPN and OpenCPN/OpenCPN. Every attempt resulted in the same problem.

As the documentation for flatpak extensions is a bit sparse (in my opinion), I am not sure that I have come up with the best solution. That said, I have tested it with oeRNC, oesENC and s63, and the approach seems to work.

[leamas]

Hm... we have so for tried to handle this by patch the plugins instead, If you look into oesenc_pi at https://github.com/bdbcat/oesenc_pi/ you can see how this is handled there, basically by

• installing the helper in a known directory for binaries (see https://github.com/leamas/OpenCPN/wiki/Installation-paths)
• Making sure this directory is part of PATH (handled by main opencpn code)
• Adding and using the new find_in_path() function to locate the binary.

At least for now; I'd prefer to do it this way just to keep the changes to the main code to a minimum until the 5.2 release is branched.

Thoughts?

[grhitch]

Hi Alec,
thanks for the quick reply.

Unfortunately oesENC doesn't work like that from the flatpak, only the tarball. OpenCPN has to be patched (or some other fix). When I had trouble trying to get s63 to work, (which I see Dave has already done - thanks Dave!) I went back to the oseENC example that you have given. It works perfectly from the tarball, but not from a flatpak install because the binaries are not mapped to a findable directory (using find_in_paths as oesENC does). The details are in the oesENC issue from examining the insides of the sandbox.

So, as I see it the problem is only if you want to have installable flatpaks. I imagined that this was an intended future route. Also I find it very covnenient for testing. If you want the only installation path to be via tarballs, then it can be left as is. If that is your choice, then I suggest removing the install lines from the Makefiles so that things are internally consistent.

I am probably taking up time that you would prefer to be spending on other things. I just wanted you to be aware of the issue for future consideration.
Thanks
Greg

[leamas]

I started with this approach, but have abandoned it with the feeling that the flatpak extension concept is not really usable as is.

So, for now I think we should focus on the tarball approach. We (really, I) should also remove lingering docs describing how to build regular flatpak extensions, sorry if you have been misguided...

You should be able to use the new "Import" function to install a plugin tarball directly for test purposes. Have you tried this?

[grhitch]

Yes I have with no success, but that is probably my fault. Will try again.
Can I suggest that the install section of the Makefiles (in the flatpak directory) be removed at some future point? Perhaps even a note to this effect as I have spent many tens of hours to find a solution. Clearly, it is not urgent if I am the only person to find this problem.
I am happy that you are aware of the issue and will close it out for now.
Thanks again

[grhitch]

Sorry misread your reply. You had clearly understood the issue with the docs. Sorry for repeating needlessly

[leamas]

The fix to flatpak/README.md is part of OpenCPN#1936.

I'm so sorry you have invested time in this after reading my outdated docs "ashamed".

Are you aware of other docs floating around which should be updated w r t this issue?

[grhitch]

Don't stress I learned lot's in the process. I found the documentation on extensions under flatpak a bit sparse, but I did end up with quite a few plugins working quite happily.
I will have a bit of a trawl through documentation this week and let you know if I find anything that I think could be adjusted.
Greg