maptool
maptool copied to clipboard
RPTools
Distribute application through Flatpak
Is your feature request related to a problem? Please describe. I'd like to install Maptools on Fedora but there is no package available for installation.
Describe the solution you'd like It would be nice if the software could be distributed as a Flatpak, for example on Flathub so that it could be installed on various Linus distros.
Describe alternatives you've considered Alternatively I could compile the application myself, but it's not ideal.
We currently use jpackage and it supports Windows, macOS, and Linux .deb install formats. It's unlikely we will be adding distribution-specific packaging formats that are not built into the existing Java tools.
Worst case, you convert the Deb to your local format, or simply unpack the Deb and use the JAR file directly. You could also submit the software to your distribution packaging team for inclusion in their repos. (Most of the time, they have automated tools for packaging Java applications, but I don't know about Fedora in particular.)
The thing is Flatpak is not specific to Fedora, it's a way to package applications for Linux so that they can run on any distro. It also sandboxes the application and ensures that there are no conflicts with local dependencies. Kind of like a Docker for desktop applications.
We actually also build a RPM with the current head of develop. Now, that would satisfy the condition to have a fedora install, but I can see benefits to using Flatpak as well... I'm not going to commit any of us to doing Flatpak, but I could look into it.
For any who are not aware, Flatpak is a method of packaging an application which would provide a consistent deployment environment by putting the dependencies into a container-like image. This would be useful as it would allow for a wider distribution on linux platforms without needing to bundle for each flavor of linux. There may be downsides or more maintenance overhead, and that is part of what I'd be looking at if I was to evaluate doing this.
This may be something worth us looking into, but it also may be infeasible due to the overhead. I don't mind looking into it and evaluating how much effort this would be, and it may be useful to reach a wider audience.
Another alternative to Flatpak might be an AppImage. I know that Flatpak by default can't access the filesystem, and may have some other security defaults, which might make it harder for us to use Maptool with it.
Flatpak is nice, but the sandboxing does add complications.
Short term, AppImage seems like it could — at least theoretically — be done more easily and has the ability to include update functionality.
A proof-of-concept for an AppImage may be to try using pkg2appimage to convert the .deb file to an AppImage, but a more proper process would allow including update functionality.
The thing is Flatpak is not specific to Fedora, it's a way to package applications for Linux so that they can run on any distro.
If you want to evaluate whether and how this would work, I’d say go for it. We can add a script to Travis that only runs on Linux builds that does additional conversion, I suppose.
If you want to evaluate whether and how this would work, I’d say go for it. We can add a script to Travis that only runs on Linux builds that does additional conversion, I suppose.
Sure, I'd be willing to try and whip something up when I have some spare time.
but a more proper process would allow including update functionality.
Yeah for sure this could be accomplished by publishing to Flathub for example, Flatpak will allow updating these kind of things through a central repository.
I threw together a Flatpak manifest that might work, although it requires network access to build, so I don't think it could be published on Flathub as-is.
I threw together a Flatpak manifest that might work, although it requires network access to build, so I don't think it could be published on Flathub as-is.
I wonder if the network share is really a blocker, and if it is, can't the dependency issue be solved with external data checker? I'm not a developer, so I don't know what I'm talking about here.
Hope someone is able to bring this to the finishing line. Flathub Maptools for the win 🤘!
I wonder if the network share is really a blocker, and if it is, can't the dependency issue be solved with external data checker? I'm not a developer, so I don't know what I'm talking about here.
As far as I'm aware, it's a pretty hard limit. The real issue isn't that the build can't access the network at all; it's that it must statically declare exactly what network accesses it's going to make. I messed around for a while trying to get that information out of Gradle, and it proved miserably difficult for someone with my level of Gradle experience. Pretty much the only way I can think of to reasonably work around the whole thing would be to do the Gradle build process outside the "main" Flatpak build and host the artifacts somewhere else, such as in a GitHub release.
As far as I'm aware, it's a pretty hard limit. The real issue isn't that the build can't access the network at all; it's that it must statically declare exactly what network accesses it's going to make. I messed around for a while trying to get that information out of Gradle, and it proved miserably difficult for someone with my level of Gradle experience. Pretty much the only way I can think of to reasonably work around the whole thing would be to do the Gradle build process outside the "main" Flatpak build and host the artifacts somewhere else, such as in a GitHub release.
Thanks for the info and your effort.
Dependencies have been a problem for deb packages recently, which further motivates the use of flatpak. E.g., libasound2 has been replaced with libasound2t64, which means our deb doesn't work on older systems that only have libasound2.
Since I didn't realize this issue existed, or that anyone had already worked on a flatpak, I've already had a go at creating a flatpak as well. My approach is to not build maptool from source, but to grab one of the linux packages from a given release and chuck its files into a flatpak. For 1.16.2, I based it on the deb package, and for 1.17, I used the new app-image zip.
Using the AppImage package as a starting point might work well. I ran into various issues trying to get Gradle working in a way Flatpak would be happy with, but if we can just download a fixed binary artifact and stick it in a Flatpak, that should be easier.