feat: flatpak preparations

[ludg1e]

This PR adds the required files for flatpak builds The PR won't be marked as ready until all pending things are solved

Pending things (if you could answer the first three below @angryziber)

• [x] Does the "any" jar pkg support aarch64/arm64 linux? If yes, then we could package aarch64 as well, it's just a modification on the manifest
• [x] On the ipscan executable (script), what does the --add-opens java.base/java.net=ALL-UNNAMED option do exactly?
• [x] Which folders does the program create at the user's $HOME directory?
• [ ] Submit into flathub

I don't know if you'd like as well for each release a flatpak file to be built with GH Actions and published under releases on this repo, or only on Flathub.

Quote from the flatpak issue #147

I can maintain the flatpak if you wish. As well the website could be updated adding the flathub link when the pkg is released.

[ludg1e]

I think I'll do as well another PR on gh-pages branch to update the website details

[angryziber]

The answers below:

1. any jar just doesn't contain any native/CPU-specified binaries and works only if your system provides Java and SWT packages built for your CPU. This was the case for Raspberian, but the jar itself is more CPU-neutral, it doesn't support ARM by itself. So probably this is not a good candidate for Flatpak.

2. --add-opens is needed for Java 11 and newer to give access to some internal classes that ipscan needs to optimize name resolution, and maybe something else. It would be wise to use the same executor script that is packaged into deb & rpm, because it may change. Same for the icon and .desktop file, I guess. Is it possible to reference them directly from source code or create symlinks?

3. I believe Java Preferences API stores some files in ~/.java/.userPrefs/ipscan/

[angryziber]

Another question is the Java dependency: will the package bundle Java or somehow a system-wide version will be used? If it is bundled, then it would be wise to build a smaller JRE using jlink as is done for Windows and MacOS builds.

[ludg1e]

Another question is the Java dependency: will the package bundle Java or somehow a system-wide version will be used? If it is bundled, then it would be wise to build a smaller JRE using jlink as is done for Windows and MacOS builds.

On the flatpak manifest it's specified to download and install before the JDK 11 freedesktop runtime, so when you install the app through flatpak cli or any GUI, JDK is installed along: Note that this JDK runtime is only available for flatpak apps and isn't installed neither system or user-wide. So, even if the user has already a JDK (or JRE) installed from repos that JDK won't be able to be used by the flatpak app

sdk-extensions:
  - org.freedesktop.Sdk.Extension.openjdk11

Afaik there isn't a JRE runtime for flatpak. More info: https://docs.flatpak.org/en/latest/available-runtimes.html

[angryziber]

@ludg1e do I understand correctly that these files should actually go to a new repo under github.com/flatpak? Is it possible to add a reference from flatpak to files in this repo?

[ludg1e]

@ludg1e do I understand correctly that these files should actually go to a new repo under github.com/flatpak? Is it possible to add a reference from flatpak to files in this repo?

The manifest has been written so the files are fetched from the /ext folder of this repo (metainfo, svg icon, .desktop...) (basically this PR) So, under the flathub GH organization only the manifest should be pushed into a new repo

[ludg1e]

The only thing that would need to be maintained is the url the manifest points to, so the version should be changed on each new release url: https://github.com/angryip/ipscan/releases/download/3.9.1/ipscan-linux64-3.9.1.jar

[ludg1e]

Nevermind, all this is done automatically by the x-checker-data from the manifest that is as well checked by the flathub bot

[ludg1e]

Though now that I think you're right and to avoid redundant files it'd be better to use the original ones I'll do a PR that pushes some modifications to the files

[ludg1e]

Continuation under #424