Supporting flatpak?

Request For Comments
21

I think the discussion on apt packages is a bit different, given it is possible to have the “system is built as a whole and subsequently a number of apt packages are created”, as you mention.

With the flatpak I can e.g. have the “base package”, or extension in flatpak speak, and use it from the terminal in visual studio code.

As far as I can tell it’s not possible to have this functionality with the normal “gui” flatpak, but I can look into it more.

22

If I understand you correctly, you’d create a base package from SWI-Prolog’s core and then you would use this to build swipl-win, where the base package would provide libswipl.so, etc.? Right?

If that is true, you might be able to build the base package as you intended. Then build a second flatpak based on the base package, where you build only the core system and swipl-win and next you only install the swipl-win component. Would that work? If it does, one price you pay is to compile the core twice, but that is not a lot. The second price to pay is that you need to download the full source twice. Might be ok. If not, we can always consider to create a tar archive with the core and swipl-win only.

23

As far as I understand from the documentation, if we have an extension (what I previously called base) for swipl, we can add that to the swipl-win package. The base package wouldn’t need to be rebuilt.

When building a new version it would:

  1. build swipl and release that “extension” flatpak
  2. build the swipl-win flatpak using the built swipl one as a dependency.

So if users install swipl-win, then the swipl flatpak is downloaded automatically, but they can decide to only download the swipl flatpak and use another text editor.

Another use case is that if I want to package another program that uses swipl I can reuse the extension.

24

I think we agree on (1). The problem is (2) as packages/swipl-win cannot be built outside the SWI-Prolog source tree. That leaves two options

  • Modify it such that it can. It is probably the easiest (foreign) package for doing this. Still, it is probably quite a bit of work. It will also block building binary packages using cpack that includes swipl-win (used for e.g., the MacOS binaries). So, we would need to ensure the cmake description works both inside and outside the source tree. Be my guest if you want to make this possible. If it doesn’t get too ugly I’m happy to merge the changes.
  • When building the swipl-win flatpak, get the entire source tree and build the core + swipl-win package only. Now only install the swipl-win component. As the rest should already be there from the extension, this should work (I think).

The latter route is somewhat less elegant, but looks like a lot less work to me.