Dne 14. 05. 20 v 11:53 Michal Srb napsal(a): > Hello, > > On Tue, May 12, 2020 at 12:57 PM Felix Schwarz > <fschw...@fedoraproject.org <mailto:fschw...@fedoraproject.org>> wrote: > > > Am 12.05.20 um 12:32 schrieb Ty Young: > > Right, I figured it was some Fedora policy and not up to you. I > suppose I > > should have been more clear there. Sorry for any confusion, it > was aimed at > > the Fedora project as a whole as this is a Fedora issue. > > This is not a Fedora issue but a consequence of Fedora's core > values. You not > agree with it but "building from source" is so fundamental that it > does not > make sense to even start a discussion about it on fedora-devel. > > I suggest you read up on the rationale behind that policy (which > is why I > linked the policy document in the first place). > > > I agree that building from sources is the right thing to do. However, > let me play devil's advocate here :) > > What makes Java apps different from other language ecosystems is that > Java apps never share dependencies. There is no concept of > "system-wide" 3rd-party Java libraries that would be automatically > added to classpath when JVM starts.
And now how is this different to different language ecosystems? All languages I have ever worked with has this attitude, more or less. The Linux distributions are fighting against this but with various success. With Java, Fedora is failing ATM. And if the bundling is not happening on language level, then we are back to bundling in containers and flatpacks and what not. Vít > I realize that this is technically possible to achieve, but that is > not how people use it. If you want to distribute your Java app, you > just bundle it with all its dependencies into a beefy tarball and ship it. > And if Java apps never share dependencies, then developers are not > really forced to keep up with latest versions of libraries. Nobody can > update the non-existent system-wide Java library that would break > their application. They are in control. > > Since there is no standard place for shared Java libraries on your > laptop, how can you use the packaged Java libraries and develop > software against them? Sure, you can hack it and make it work on your > Fedora 32 machine, but your custom Makefile is not guaranteed to work > on Fedora 31 or later on 33. And your colleague that is on CentOS is > out of luck of course. And so are all your potential external > contributors on their MacBooks and Ubuntus. > What I am trying to say in this paragraph is that shipping (in RPMs) > and maintaining individual build-only Java libraries is, at least in > my opinion, questionable. > > Fedora and other linux distributions are trying to do the right thing, > but things like Java apps simply don't fit in. What Java app > developers are doing may not be the best thing, but it's been like > that for ~20 years, and it seems to be "good enough" for the majority > of people involved (well, developers at least). > Fedora alone is too insignificant to change it I am afraid. > > However, with all that being said. I do like "dnf install my-java-app" > better than unpacking some tarballs somewhere. > > And finally, here comes the "devil's advocate" part of my email. > > * building Java libraries and apps from sources? > * +1, no doubt about this > * building Java libraries and apps from sources in a controlled and > reproducible environment? > * yes, please > * building Java libraries and apps from sources from SRPMs? > * do we really need the RPM overhead here? > * shipping (in RPMs) and maintaining Java libraries that are not > runtime dependencies of Java applications that we want to have in Fedora? > * nope, why? build such build-only dependencies from sources, make > sure they are OK license-wise, but do not ship them to users (as > explained above, they are not very useful for developers anyway) > > We can do license reviews, we can build from sources, but we don't > necessarily have to do all this in RPMs. > We can do all the right things, store (our binary) results in a > language-native way, which would be a Maven repository controlled by > Fedora in this case, and then simply wrap our good binary JARs into > RPMs, without rebuilding them all the time. > > Note having such language-native repository full of good and reviewed > Java libraries would mean that developers that care about such things > could actually start using it instead of the official Maven > repository. And they wouldn't be tied to a specific version of Fedora > or Linux. > > I don't think this would go against the current packaging policy, it > just would be *a ton" of work :) > > This email turned out to be way longer than I expected it to be, but > Java packaging is a complicated topic. > > Thanks, > Michal > > > > I understand that missing components/features due to the source > requirement > are annoying but Fedora (and other distros) decided to take the > "high road" > here and actually fix stuff instead of shipping whatever upstream > came up with. > > Felix > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > <mailto:devel@lists.fedoraproject.org> > To unsubscribe send an email to > devel-le...@lists.fedoraproject.org > <mailto:devel-le...@lists.fedoraproject.org> > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
