Some app extension questions

Stephan Bergmann sbergman at redhat.com
Thu Aug 5 10:04:03 UTC 2021


Hi all,

I'm trying to add an extension point to the LibreOffice app, so that 
"bundled extensions" (which is LibreOffice jargon for LibreOffice 
extensions that are installed directly into the application, rather than 
by each user individually via the LibreOffice extension manager UI) can 
be provided as extension flatpaks, and ran into a few questions:

* <https://github.com/flathub/org.libreoffice.LibreOffice/pull/158> "Add 
an org.libreoffice.LibreOffice.BundledExtension extension point" 
introduces the extension point,

>          }
>      ],
>      "add-extensions": {
> +        "org.libreoffice.LibreOffice.BundledExtension": {
> +            "directory": "libreoffice/share/extensions",
> +            "subdirectories": true,
> +            "no-autodownload": true,
> +            "autodelete": true
> +        },
>          "org.libreoffice.LibreOffice.Help": {
>              "directory": "libreoffice/help",
>              "bundle": true,

I observe that without any extensions installed, the original content of 
/app/libreoffice/share/extensions/, namely a package.txt file, is 
present, but disappears once any extensions are installed (which each 
add a subdirectory to /app/libreoffice/share/extensions/).  Is that a 
bug, or a feature, or a misconfiguration in the json file?

* Each extension flatpak must apparently have an id matching 
org.libreoffice.LibreOffice.BundledExtension.XXX, where XXX must match 
the directory /app/libreoffice/share/extensions/XXX/ into which the 
extension's files go, and where XXX must not contain dots (or else I get 
errors like

> error: No extension point matching org.libreoffice.LibreOffice.BundledExtension.org.puimula.ooovoikko in app/org.libreoffice.LibreOffice/x86_64/test

when flatpak-builder'ing such an extension).  Is there a way to relax 
that no-dots restriction?  (There apparently needs to be some way to 
ensure uniqueness of those XXX parts, and LibreOffice extensions already 
have their own unique <identifier> scheme, using dotted 
reversed-domain-name notation, so a natural---though verbose---choice to 
guarantee unique XXX parts would be to use 
org.libreoffice.LibreOffice.BundledExtension.<identifier> as the id of a 
flatpak extension that packages a given LibreOffice extension.)

* 
<https://github.com/stbergmann/org.libreoffice.LibreOffice.BundledExtension.Voikko/> 
is such an extension.  It needs two build-time modules, libvoikko and 
foma, which for now I install to 
/app/libreoffice/share/extensions/Voikko/build-deps/ (because everywhere 
else appears to be read-only during the build) and then try to remove with

>     "cleanup": [ "/libreoffice/share/extensions/Voikko/build-deps" ]

But that cleanup does not seem to work the way I expect it, the 
populated /libreoffice/share/extensions/Voikko/build-deps/ directory is 
still present in the resulting flatpak.  Is there some better, ephemeral 
place to install those build-time dependencies to, and/or how to fix the 
cleanup?

Thanks,
Stephan



More information about the Flatpak mailing list