newbie question #2: plugin-based applications

John Stebbins JohnAStebbins at jetheaddev.com
Tue Jul 3 14:55:35 UTC 2018


On 07/03/2018 04:49 AM, Alec Leamas wrote:
>
> On 02/07/18 17:39, John Stebbins wrote:
>> On 07/02/2018 02:27 AM, Alec Leamas wrote:
>>> On 02/07/18 03:59, John Stebbins wrote:
>>>> On 07/01/2018 04:54 PM, Alec Leamas wrote:
>>>>> Has anyone a working example how to build an extension like this i. e.,
>>>>> something which extends an app rather than a runtime?
>>>> flatpak-builder certainly does support building an extension like this. 
>>>> I think you may be getting misled by the line
>>>>
>>>> "runtime": "io.github.Hexchat",
>>>>
>>> Indeed, thanks!
>>>
>>> Still, the road is bumpy for an apprentice, it's hard to find
>>> documentation. I have managed to build my extension/plugin, but:
>>>
>>>   - I can see the installed stuff in /app/extensions/ShipDriver; here is
>>> a generated manifest file and the files I have installed  in lib/ and
>>> share/ when using flatpak-builder --run ... bash
>>>
>>>   - I can install the plugin package.
>>>
>>>   - But, when I check the sandbox for the main package, there is nothing
>>> under /app/extensions using flatpak run --command=bash ...
>>>
>>> I guess I have missed something, again. Thoughts?
>>>
>>>
>>> Cheers!
>>>
>>> PS: Extension manifest:
>>> https://paste.fedoraproject.org/paste/HrdjBjXDPa0m8oQ1SocEug
>>> motherboard manifest:
>>> https://paste.fedoraproject.org/paste/wLDtqwewm8OWSqurjaQrxw
>>>
>>>
>> I'm not sure but it may be due to how you specified runtime version.  Remember the "runtime" in this case is OpenCPN. 
>> It looks like you set the runtime-version to the version of org.freedesktop.Sdk instead of OpenCPN.
>>
>> runtime-version: 1.6
>> sdk: org.freedesktop.Sdk
>>
>> should probably be this instead (unless you set some other branch with --default-branch option of flatpak-builder when
>> building OpenCPN)
>>
>> runtime-version: master
>> sdk: org.freedesktop.Sdk//1.6
>>
> Still ashore, got things working. I have not really sorted out all the
> pieces, but fixing the version (which I had worked around by publishing
> opencpn as 1.6. Ouch..) and reverting to json seems to settle things.
> Filed a bug about the yaml parsing (179).
>
> Now, I need to patch opencpn to load plugins also from
> /app/extensions/lib/opencpn. This is perfectly doable, just some time to
> get into that code.
>
> But, I also need to patch any plugin flatpaked to use their own text
> domain (with locales under /app/extensions/share/locales) and also to
> get their own data from /app/share/opencpn/plugins instead of
> /usr/share/. I'm not really looking forward to this...
>
> So: is there any way to merge e. g., /app/lib/opencpn and
> /app/extensions/lib/opencpn? Or some other approach?
>
> Thoughts? Many thanks for help so far!
>
>

In general, any app (or plugin) should always look for such things (locales and own data) in $PREFIX/share/blah... 
where prefix is set with the --prefix option of configure.  Any app (or plugin) that doesn't do this needs to be *fixed*
with a patch anyway and patch pushed upstream ;)

Note that when building a flatpak extension, flatpak-builder for some reason I don't understand sets --prefix=/app by
default which would cause a problem.  But fortunately it supplies a correct FLATPAK_DEST variable which can be used to
set the prefix configure option correctly when building modules.  E.g.

            "build-options": {
                "prefix" : "${FLATPAK_DEST}"
            },


-- 
John      GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01  83F0 49F1 D7B2 60D4 D0F7


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/flatpak/attachments/20180703/b16597e9/attachment.sig>


More information about the Flatpak mailing list