Supporting flatpak?

Although it proved possible to build a snap image for SWI-Prolog on Fedora, snap is primarily a Canonical product. Flatpak is similar and promoted by most Linux distributions. That made me think to provide a flatpak image for SWI-Prolog.

This turns out to be fairly simple. The current manifest and build instructions are at GitHub - SWI-Prolog/flatpak: Manage Flatpak image (probably temporary here)

The build works fine using the current swipl-devel.git version (a patch was needed because all files in the flatpak have their modification set to the Unix epoch and this was given a special meaning in the file admin of SWI-Prolog).

Does anyone here have experience with Flatpak and is willing to help to turn this into a properly working release on https://flathub.org/? Some issues that need attention

  • As is, the flatpak linter gives some errors and warnings.
  • The flatpak version currently lacks jpl, odbc, bdb and native UUID.
  • It is currently about 25% slower than the natively compiled version. I suspect that is due to the CFLAGS that are eventually used. Gcc 14 that I’m using for native compilation can’t be that much better than gcc 13 used by the flatpak sdk.
  • How can we start either swipl-win (Qt console) or swipl (in terminal)?
  • What should the sandbox permissions be?
  • It has Python and (thus) Janus. How much use is that? (How) can people add Python packages to this version?
  • Get flathub release published.

Hi jan,

The flatpak is fairly limited as well.
Flatpaks are not meant to be used for CLI programs, nor is it possible to have multiple commands (like the terminal and qt-console).
The sandbox permissions are editable, so it would be fine to find a sensible default, and let users override them.
Regarding python, if you were to bundle it in the flatpak it would not integrate with the system one, so it wouldn’t be too useful.
Having said this I can give it a look and see if some of the issues are avoidable.

To publish it it might have to default to the GUI (qt) version.

Thanks. Flatpaks seem to handle CLI applications just fine. At least, if I make swipl the command, it just works. Only, the way to run is not so nice (flatpak run id [arg ...]) As with the snap, making swipl-win the main executable seems the most sensible. That works just fine.

Finding a sensible solution to use Python, Java, odbc, etc. would be nice. But then, we do not have a solution for that for snap as well and as I understand it, the MacOS bundle already has some problems here and it is likely to get worse. Distributing software doesn’t get any easier :frowning:

If you have time to have a look and give some comments, please do. I started a freedesktop MetaInfo file. That still has to be finished and put into some sensible location.

With a metainfo file, and a .desktop launcher (for the default swipl-win) the other warnings have been removed already.
The x11 warning simply requires replacing --socket=x11 with --socket=fallback-x11 (since the default is wayland).
Once it works we can then open the PR on the flathub repo on github, so it appears on flathub.
The python, java, odbc, … issue is harder to solve.
With the snap we could make it classic, so it has access to other programs installed (e.g. python/java), with the flatpak I’m not sure that’s possible. There are limited ways of breaking out of the confinement, but nothing as broad.
It’s possible to run host programs, by giving special permissions then running flatpak-spawn --host <command>, but I’m not sure that’s enough.

That unfortunately is not true. swipl-win is a Qt application and what would run fine with --socket=fallback-x11. SWI-Prolog’s only GUI tools are plain X11 though. So, I think the option is to use --socket=x11, forcing Qt to use X11 or give both, allowing Qt to do its thing and Prolog as well (X11).

Each has its own problems. Python is inside the kde runtime, but this does not need to be the same version as on the host. As we link to libpython<version>.so and we do not know which version runs on the host, it is practically impossible to use the host version. Possibly we can install Python packages that use the Python of the Flatpak? That would at least deal with half the problem. Java is not in the kde sdk. It we have a way to link in host .so files, we are fine though as the JNI interface is binary compatible between Java versions (as opposed to Python). ODBC is not in the sdk either.

There seem to be a whole range of flatpak types though. Some of the naming seems to suggest you can use one flatpak as a plugin to another. If that is true, there could be solutions?

I agree that the best step forward is probably to fix the MetaInfo and .desktop issues, get it accepted on flathub and see from there were it goes. That should probably be with the next release as they seem to like release files and the current release does not run in a Flatpak :frowning:

So far, I like the fact the SDK poses far fewer problems than building snaps and is a lot quicker.

Ah ok. In that case we could remove the wayland socket, as that would not be used in theory. I don’t think it’s used for anything else (Sandbox Permissions - Flatpak documentation)

The issue using the python version in the runtime is that everything would need to be run in that runtime, and that might not be ideal (if a program makes use of other libraries).

There are also java (openjdk) runtimes, so one thing that might be feasible is to add those.
It might be feasible to add them as non essential dependencies, using plugins/extensions (Extensions - Flatpak documentation).
It might also be possible to add the filesystem access to the necessary host .so files.

I temporarily updated the flatpak manifest here: GitHub - LyzardKing/swipl-flatpak: Manage Flatpak image (probably temporary here)

Mainly added the appinfo/desktop/icon (from the snap). It can be changed later.
Haven’t looked at the extensions much, but there are other flatpaks that can be used as a reference for that.

It works if I manually clone the repository and run from the local version, but I get this error (at runtime) after building with the github repository as a source instead of a local folder:

ERROR: /app/lib/swipl/library/predicate_options.pl:53:
ERROR:    with_mutex/2: C-stack limit (8,388,608 bytes) exceeded.
ERROR:    Use the shell command 
ERROR: /app/lib/swipl/library/dialect/swi/syspred_options.pl:42:
ERROR:    sig_atomic/1: C-stack limit (8,388,608 bytes) exceeded.
ERROR:    Use the shell command ulimit -s size to enlarge the limit.

It continues reporting issues like this, and never gets to a prompt.

Thanks. I was planning to take the route to add a MetaInfo file and generate the desktop info. I have a basic setup of that, but all should go to the right place. I think the MetaInfo should get some place in the main repo rather than the Flatpak
repo, no?

It should work if you use the HEAD of swipl-devel.git. The critical patch is dd7f4bdcaeec01f3c555d30a160de16195af190c. It appears Flatpak sets the modification time of all files to 0 (Jan 1 1970), but SWI-Prolog used the 0 value to indicate the source file was not loaded. So, it keeps loading in a loop until it runs out of stack. That patch keeps track of the loaded status in a flag rather than misusing the time stamp. I was still naive when I wrote that :slight_smile:

P.s. What should be the application id? I thought that should be org.flatpak.swi-prolog, but I now think that flatpak is not needed there. Than org.swi-prolog.swipl-win would make more sense, but it the MetaInfo checker tells me that dashes are not allowed in application ids :frowning:

The desktop/icon/metainfo can reside in the main repo, I added them there for testing.
The metainfo has to respect the same rules as the flatpak yml regarding filenames (the application id), and should be installed in the correct destination (through cmake?)

The other thing I added (for which I wanted to use the github tags) is to get flathub to automatically generate a PR on a new release (tag), to check that it builds correctly. Then the new version can be automatically or manually merged.

The application id needs 3-4 parts. It can be either something like org.swi_prolog.swipl or org.github.swi_prolog.swipl (Requirements & Conventions - Flatpak documentation)

I wouldn’t set it to swipl_win, as it would also be the application name.
The dash (-) is allowed only in the last element.

Thansks. All useful steps :slight_smile: I’m afraid I need to do some work for a customer first :slight_smile:

I can open the PR on flathub, so it starts building as it would on their infrastructure, to test it.
Then we can always move the desktop/metainfo/… to the main repo later.
The only thing to figure out before uploading is the name.

If you think org.swi_prolog.swipl-win is more descriptive of the package then it’s fine, and it would respect the requirements.

I doubt. It keeps the route for a non-Qt version as org.swi_prolog.swipl open. I have no clue how useful that is though. Do what you think is best. I guess it is not possible to have two .desktop files for a single Flatpak?

Please give it a try!

Thanks!

No, only one .desktop (and one default command).

As you mentioned you can run other commands via flatpak run --command=... but it’s not really the intended use.

An alternative is to keep the non-qt version as default, adding terminal=true in the .desktop file.
That makes it so when launching from the desktop menu the terminal is opened (as if opening a terminal and running swipl)

I thought about that as a possible second .desktop. As that doesn’t work and I think the flatpak first of all targets new users, I think the Qt console is as good as we can do.