phoenicis
phoenicis copied to clipboard
PhoenicisOrg
Provide a RPM
Originally brought up from here: https://github.com/PhoenicisOrg/POL-POM-5/issues/1190
An RPM should be included to help build and distribute the Jar file across other platforms other than Debian and Ubuntu. I will be working on initial support for Fedora and RHEL/CentOS and plan to have this completed in April. It should be relatively easy to eventually add in support for other RPM-based distributions such as openSUSE and Mageia as well. This needs to be able to work with the current maven build system.
I think we can use https://ctron.github.io/rpm-builder/ to create a RPM installer.
@madoar I had the impression that @ekultails knows how to do it (doesn't do this for the first time).
@plata it wasn't my intention to tell him, how this issue must be solved. Whoever wants to give this a go is free to do it however he wants. I just wanted to add my own findings, I found while working on another project some time ago.
The Java RPM Builder plugin looks very interesting and could potentially be easier than writing an RPM spec file from scratch. I don't have any experience with that plugin and it would be good to at least do some more research into that first since it integrates with Maven.
Before having an RPM implemented, details for setting up Phoenicis on Fedora based operating systems should be fully sorted out: https://github.com/PhoenicisOrg/phoenicis/issues/1157. I will need to do some additional research and testing on this.
I'm on manjaro now. But can install a fedora next to it for testing purpose if needed (use fedora for 5 year so)
Do we still need this? To be honest, I would prefer to streamline distribution and support only flatpak.
Yeah I think it is important if we could automate the creation of deb/rpms if we want to be integrated inside the official distributions repositories
We can achieve the same with flatpak. E.g. in Ubuntu, you can install flatpak applications like any other application from the software center.
Flatpak is interesting but I can't use it on my laptop. Not enough free space left for all that duplicate libraries XD
Was talking about flatpak in general. It's just I use some program than require the same library. So I got 3 or 4 duplicate of each libraries. I suppose that java is in the runtime part of flatpak ?
I didn't check how big flatpak itself is (including the runtimes). But honestly: if you do not have enough space for that, you cannot install any apps with Phoenicis anyways. Yes, the normal Phoenicis Java application is running inside the flatpak.
Ok... The Phoenicis flatpak is 312MB (according to software sources).
That's exactly why I would prefer .deb and .rpm.
To save some MB? That really shouldn't be an issue nowadays. From my perspective the situation is as follows: our man power is rather limited, so we can either decide to support several ways of distribution and handle all the problems which come with that, or we concentrate on the software, ship one flatpak and save the additional effort.
The problem is that having flatplaks or snaps alongside regular .deb makes lots of duplicate libs (since, if I understand correctly, flatpaks apps use their own "sdk" and does not interact with other .deb on the system). Flapaks and snaps seems also to be bigger than .deb (since dependencies are included in them (multiple times)). Since .deb are working, I will go with that.
I think flatpak is interesting but we just come with something Windows already done (better but still, with the same cons). For POL, I suggest to start with it. I may don't like the system but @plata is right, we aren't enough here to provides POL on the requested distro.
I agree with @plata, that we have a limited number of developers, who have a limited amount of development time for this project. If we support a larger number of distribution choices, this will require an increasing amount of maintenance over time. In addition not every developer can test all distribution choices. For example I don't own a Mac PC and therefore can't test on OSX.
The issue is not that we refuse to support .deb and .rpm, but that we aren't really able to maintain them ourselves. This also means, that if an .deb or .rpm installer is desired by the community, we require someone from the community who agrees to maintain it later on.
Since it is already the case for the POL4 .deb (which is in multiverse in ubuntu), I'm nearly sure that someone in the community will be maintaining a phoenicis one.
we could provide the flatpak as default one (aka fallback). and provides specific package with the community if asked ?!
I believe the biggest problem we face with supporting most package/distribution choices is the spectrum of available Java versions on the operating systems.
The project setup currently targets Java 8, which is still supported and used by quite a lot of people. Starting with Java 9 a module system has been introduced to Java, which requires some changes to the project setup to be compatible. Starting with Java 11 JavaFX/OpenJFX (which is the GUI framework we're using) has been moved to its own project/module.
The flatpak distribution uses Java 11 behind the scenes, which is quite useful because we don't need to cope with different Java versions. While working on the flatpak distribution @plata stumbled over quite a lot issues to make Phoenicis run on Java 11. In my opinion the biggest issues are the aftereffects of the module system introduction in Java 9 and the JavaFX restructuring in Java 11. I think, that both issues can only be cleanly solved by changing the project setup to target Java 9 or 11. This in turn prevents people who still use an older Java version from installing Phoenicis, if they use a distribution method like a .deb installer.
I couldn't agree more with the explanations @madoar provided above. To be really clear once more: we will not prevent anyone from providing/using deb/rpm etc. We just cannot afford to solve issues arising from certain Java versions, runtime environments etc. here (this is something the distributors should care about).
I think we can solve this problem now that we have a new package creation process. Let's try to do it for alpha-3