How to add symbolic link to an external package

1

I have installed the latest version of LibreOffice through Flatpak, and the newest version of a LibreOffice extension, WritingTool (meant as an offline grammar and orthographic checker, instead of using LanguageTool online feature), which requires Java RE enabled.
Although with WritingTool extension active and the buttons appearing in the toolbar and the file bar, clicking on any buttons do nothing. The dependency of Java active seems to make the extension slow to respond, and prone to crashes… My LibreOffice install specifications are:

Version: 25.2.2.2 (X86_64) / LibreOffice Community
Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac
CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: gtk3
Locale: pt-BR (pt_BR.UTF-8); UI: pt-BR
Flatpak
Calc: threaded

I have the package ‘libreoffice-java-common’ installed from the repositories of my Linux distro (MX Linux 23.6), but apparently LibreOffice Flatpak install doesn’t ‘recognise’ it… And, unfortunately, libreoffice-java-common isn’t available at Flatpak repositories (neither flathub nor flathub-verified …)

Supposing that, in my case, the trouble is due to absence / non-recognition of package libreoffice-java-common, how to add a symbolic link in flatpak to an external package?…

A quick search with Google returned this:>

To create a symbolic link to an external package within a Flatpak, you’ll primarily use the ln -s command, similar to how you would on a standard Linux system. This creates a symbolic link (a pointer) from within the Flatpak’s environment to a file or directory located on the host system outside the Flatpak.

Steps:

  1. 1. Identify the External Package:

Determine the exact path of the file or directory you want to link to from the host system.

  • 2. Determine the Target Path Inside the Flatpak:

Decide where you want the symbolic link to be created within the Flatpak’s file system. This might be within the app’s config directory, or another location accessible to the app.

  • 3. Create the Symbolic Link:

Use the ln -s command from inside the Flatpak’s environment to create the link. The command syntax is: ln -s <path_to_external_file> <path_to_symlink_in_flatpak>.

Example:

Let’s say you want to symlink a configuration file located at ~/my_configs/app_config.ini on your host system to a Flatpak application that expects this config file in its ~/.var/app/com.example.app/config/ directory.

  1. External Package: ~/my_configs/app_config.ini
  2. Target Path (Inside Flatpak): ~/.var/app/com.example.app/config/

The command to create the symlink would be (from within a Flatpak terminal, or using flatpak run --filesystem=host com.example.app --command=bash):

ln -s ~/my_configs/app_config.ini ~/.var/app/com.example.app/config/app_config.ini

Important Considerations:

  • Permissions:

Ensure the Flatpak application has the necessary permissions to access the external file or directory, especially if it’s outside your home directory. This might require using flatseal or other tools to configure the Flatpak’s permissions.

  • Flatpak Sandboxing:

Flatpak sandboxing can restrict access to certain parts of the host file system. If the external file is in a directory not explicitly allowed in the Flatpak’s configuration, the symlink might not function as expected.

  • File Systems:

Symbolic links can span different file systems. However, Flatpak sandboxing can limit the visibility of certain file systems.

  • Persistence:

If you want the symbolic link to persist across Flatpak updates or reboots, make sure it’s created in a location that is not cleared on updates or reboots. For example, /var/lib/flatpak is a good place for persistent symlinks.

  • Testing:

Verify that the symbolic link is working correctly by accessing the linked file or directory from within the Flatpak application.

In summary, creating a symbolic link to an external package within a Flatpak is a straightforward process, but you need to be aware of Flatpak’s sandboxing and permission mechanisms to ensure it functions correctly.

In short, I’d like to assure the aforementioned procedures suffice to make the Java dependent extension works correctly within Flatpak’s LibreOffice…
Thanks in advance!

2

Symbolic links to places outside of an Flatpak application are difficult. To keep it short: The filesystem an Flatpak application sees is a sandbox, into which the files of the runtime, the application and other permitted folders are mounted to. A symbolic link to /usr for example will link to files of the runtime inside the sandbox, not your system.

That being aside, symlinking random files does not seem like a good solution to fixing an issue.
The LibreOffice Flatpak comes with an OpenJDK 21 installation, so I presume that the contents of libreoffice-java-common is also included in the Flatpak.

If the extension fails, this could be for two issues. First, the extension might be configured wrongly or makes expectations which aren’t true in the sandbox. Second, there might be some other component which isn’t included in the Flatpak.

For the second case, it seems like you can extend LibreOffice with an extension, which could add additional files to the sandbox.

With all that said, this seems more an issue to be discussed with the developers of LibreOffice or the extension in question.

3

Hi, I’m returning to this discussion after a while. Unfortunately, your last reply didn’t bring a solution… The missing package libreoffice-java-common isn’t included among LibreOffice stable release available at Flatpak. And I couldn’t find out so far a way to install it inside Flatpak, neither make some sort of symbolic link to that package I have installed in my system (from my own Distro’s repositories), although that way isn’t advised… I don’t want to resource to install LibreOffice from another source rather than Flatpak, but the absence of one single file seems to be the culprit of the almost complete inoperative condition of LibreOffice extension I need (a grammar checking resource, without depending on online connection…)
Whom I might contact to ask for the inclusion of aforementioned file into LibreOffice install at Flatpak?
Thanks in advance.

4

So, I have checked the Debian version of the libreoffice-java-common package, and it seems like the Flatpak contains pretty much all files in there already. In the app sandbox, they can be found under /app/libreoffice/….
So the files are already included in the Flatpak.

It seems to me then that the extension fails to detect their presence then. Granted the /app prefix Flatpak uses for the files of an app is unusual, and it doesn’t help that LibreOffice itself seems to break the prefix conventions itself a bit…

I would first discuss this with the developers of the extension. If the extension uses some hard path, like expecting the files under /usr, this might be the issue. If needed, an additional issue can be raised on the LibreOffice bugtracker later on.

5

I thank you your kind attention and interest on helping me with this issue. Nevertheless, I couldn’t find the files referred to libreoffice-java-common at the place you mentioned: /home/~/.var/org.libreoffice.LibreOffice/ …?

But your remarks referred to how unusual are the " /app prefix" Flatpak uses for the files, and how about LibreOffice itself seems to break loose on using of prefix conventions, which could be eventually another trouble… Or, further, in case WritingTool extension uses some hard path, expecting the files under /usr, be the real culprit.

I will try to discuss these findings with the developers of the extension, as per your suggestion. And I’ll try to add this discussion into LibreOffice bugtracker as well.
Thank you!

6

The folder ~/.var/app/org.libreoffice.LibreOffice contains user data and configuration.

What you’re looking for would be found in the app installation.

There are two common installation folders:
/var/lib/flatpak for the system installation, and ~/.local/share/flatpak for the user installation.
In there, in the folder app/org.libreoffice.LibreOffice/current/active/files you find the files that will be mounted to /app inside the sandbox.

Well, considering that in the sandbox the /usr prefix is reserved for the runtime, the /app prefix is used to mount the files an application itselfs provides. Also, LibreOffice stores its data files under /app/libreoffice/share, while I think it should be ideally under /app/share/libreoffice , which in turn would follow the filesystem conventions better.

While Flatpak and LibreOffice itself should account for this, there could be some expectation in the extension that looks at /usr still. But that’s just a wild guess.