Package GreatSPN for Arch-based (pacman) systems

[MrHedmad]

To allow GreatSPN to be installed by pacman on ArchLinux and Arch-based flavours of linux, GreatSPN would need a PKGBUILD file with compilation and other installation directives.

I'm not familiar with the project to produce a source-code package (i.e a greatspn package that downloads the source code and locally compiles it), but I was able to produce a PKGBUILD file that installs the binaries for GreatSPN from the release .deb file already provided (i.e a greatspn-bin) package. I've not yet submitted to the arch linux user repository, but I've made the build files available here: https://gist.github.com/MrHedmad/817465ad6c488f03d5cdc17196f561eb

I'm writing this issue to point out two things:

• I am not sure that my simple PKGBUILD is sufficient to correctly install GreatSPN (though an empirical test shows that it does indeed work), and would like the opinions of the GreatSPN maintainers;
• I want to raise the issue of adding Arch Linux as a supported distro for GreatSPN, either through making a greatspn package that locally compiles GreatSPN or just through the greatspn-bin package that I've provided a prototype to. If the binary release is to be preferred, a way to download the required files in a simple, generic .tar file would be optimal, to stop relying on the .deb file.

[amparore]

I don't know enough about pkgbuild to assess the correctness of this script. Since none of the maintainers of GreatSPN (that I'm aware of) currently use Arch, it would be difficult to support it. I don't understand the point about "stop relying on the .deb file". Beware that the source address in your script inside source_x86_64 point to a URL in a datacloud that sometimes needs to be updated, and the randomly generated ID will change unexpectedly.

Currently, GreatSPN builds the binary packages using the jpackage tool of Java/openJDK. This tool does not currently support Arch, for what I know. I would rather have jpackage to be capable of directly building Arch packages, instead of trying to build a custom package just for Arch by modifying another package (although such reverse-engineering of a .deb file is surely possible). Consider that jpackage does quit a complex job in building a portable Java application. You can find the unified build script for Linux/macOS/Windows here.

[MrHedmad]

Thanks for the reply. With "stop relying on the .deb file" I meant to stop "reverse-engineering" the .deb to adapt it to arch. Good to know that the download URL from the cloud changes... I guess that local compilation from the source code is inevitable to in theory package it with Arch.

I don't know much about Java, C or jpackage to comment on having a build file just for Arch, but a cursory inspection of the docs for jpackage show that it does not support Arch. With more information on the build process of GreatSPN I might be able to regenerate the .deb package from the source code (or even stopping at the app-image), and then (not so ceremoniously) "installing" that similarly to what I did already. In this way, no download would be needed from the datacloud, just from GitHub.

[amparore]

jpackage has the advantage of building a self-contained Java application, with a portable Java virtual machine. In that way, the package does not require the user to install a specific version of Java. The process is very straightforward, but of course the tool has its own limits. Consider that it generates several pre/post installation commands in the deb/rpm packages, command that one should avoid replicating manually. To build GreatSPN from sources, you can either follow the instruction, or have a look at the Docker self-compiling build file.

[MrHedmad]

To have compilation handled by makepkg (what Arch uses to produce its installable packages), one would need to package all the dependencies too, and this has been done only for the spot library. I lack the time or knowledge to support the packaging of all of these libraries by myself.

In any case, I guess it would be better to bundle Java in the application even when compiling from source. So there would not be much of a difference between the self-compiled version and the one provided as a binary here.

Consider that it generates several pre/post installation commands in the deb/rpm packages, command that one should avoid replicating manually.

If you mean the commands that add and remove the XDG entries from the start menu, I've already included those in my example PKGBUILD.

I can start using GreatSPN as installed with the PKGBUILD above. If the program runs fine, the only issue I see from publishing my method on the Arch Linux User Repository would be the fact that (as far as I can see) the binary repository on the datacloud only holds the latest release, so one would not be able to install a previous version without compilation from source.

[amparore]

closing due to inactivity/non-issue.