Some app extension questions
Alexander Larsson
alexl at redhat.com
Thu Aug 5 10:38:45 UTC 2021
On Thu, Aug 5, 2021 at 12:04 PM Stephan Bergmann <sbergman at redhat.com> wrote:
>
> 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?
Yeah, this is expected. Technically what happens is that
/app/libreoffice/share/extensions is a read-only directory mounted
into the app, and to add stuff there we need to create directories for
the mountpoints. This happens by first mounting a tmpfs over this
directory and then creating the mountpoints in that. This will hide
the original content of the directory.
> * 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
Yeah, the ids are very sensitive for flatpak. So this is not doable.
However there are some workaround you can use.
For example, there is a merge-dirs key you can set in the extension
point. Typically you set it so something like "lib" which will create
a toplevel merged dir called "lib" next to all the extension dirs
contain symlinks into all the files in the extensions that have a lib/
subdirectory.
So, you could call the extension point
org.libreoffice.LibreOffice.BundledExtension.ooovoikko, but with a
subdirectory called extensions that has a directory called
org.puimula.ooovoikko . Then if you say merged-dirs=extensions you
would get a $extensionpoint/extensions/org.puimula.ooovoikko symlink.
> *
> <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?
I think it needs to be
"cleanup": [ "/Voikko/build-deps" ]
but i'm not 100% sure.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl at redhat.com alexander.larsson at gmail.com
More information about the Flatpak
mailing list