Dne 14. 05. 20 v 11:53 Michal Srb napsal(a):
Hello,
On Tue, May 12, 2020 at 12:57 PM Felix Schwarz
<fschwarz(a)fedoraproject.org <mailto:fschwarz@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(a)lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>
To unsubscribe send an email to
devel-leave(a)lists.fedoraproject.org
<mailto:devel-leave@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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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