On Thu, May 14, 2020 at 2:42 PM Vít Ondruch <vondr...@redhat.com> wrote:
> > 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> > 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. > Since Java apps always ship their dependencies in tarballs, it's like upstream is pinning down dependencies to specific versions. There is no room for any version ranges like for example "as long as you have java-lib>=2.3 on your system, the dependency will be satisfied". Installing (well, "unpacking") other Java application that requires java-lib>=3.0 will never break the first app. Then Fedora comes in and tries not only to run both Java App #1 and Java App #2 on the same system, ideally with the single version of java-lib(latest), but also to build both the apps on the same system (the build system being the 3rd Java app). I am not saying this is something bad, it's just something completely unnatural for the Java App ecosystem. Java developers ship their tested self-contained tarballs which work on Linux, Mac and Windows. And Linux distributions take those apps and try to run them with a completely different set of dependencies. I kinda understand why upstream projects are not always happy about that... Although you're right that there are plenty of Python projects out there that straight up tell you to isolate their applications in a virtual environment when you're pip-installing them from PyPI. It's not all though. There are still plenty of projects that tell you that as long as you have python-lib>=2.3 on your machine, you will be fine. This makes Python packaging so much easier, at least in my opinion. Such Python apps are not in full control of their dependency chains, they realize that newer python-lib could introduce some breaking changes and if you open a pull request with a patch, they are not surprised, they know what the problem is and why the pull request should be merged. That's what they signed up for by saying that python-lib>=2.3 is fine. Thanks, Michal > 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 >> 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 > > _______________________________________________ > 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
