Re: The Future of the Java Stack (also regarding ELN and RHEL)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Sep 12, 2020 at 11:05 AM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
>
> On Sat, Sep 12, 2020 at 10:32:51AM +0200, Vitaly Zaitsev via devel wrote:
> > On 11.09.2020 18:42, Zbigniew Jędrzejewski-Szmek wrote:
> > > I'm not enthusiastic about build-time-only packages, but if the choice
> > > is between that and retiring the packages (or hiding them in modules
> > > which has the same effect), I'll take it.
> >
> > This will be Modularity 2.0. All packages must be installable if the end
> > user wants to do so.
>
> The packages *would* be trivially installable. I didn't say that explicitly,
> but you would always be able to install a package that has "Provides:fedora-build-time-only"
> and then install any such packages on any system. (That is how they would
> installed in mock or koji too.)
>
> > Check header-only C++ libraries packaging. They provide only the -devel
> > and virtual -static subpackages and can be easily installed in Koji/mock
> > or directly.
> >
> > Also check Rust packaging. They build crates to a separate packages and
> > use them only for the static linkage.

Hm, that comparison doesn't fit that well.
Let me try to clarify some things that have come up in this discussion
a couple of times, probably because the confusing "build-only
dependencies" vs. "source-only dependencies / static linking":

TL;DR: Java packaging in fedora is more like python packaging than
Rust packaging.

- Java code is compiled into architecture-independent bytecode (.class
files) that's usually bundled into Zip files with some metadata (.jar
files).
- That bytecode is - and can be - used at both build-time and at
runtime by dependent packages, so it's basically like Python packages.
On the other hand, Rust packages only contain source code, which is
*freshly compiled every time it's used* in dependent packages and then
statically linked.
- The "build-only dependencies" with respect to Java packages (as
mentioned in this thread) refer to *build tools* (like maven and ant)
and their dependencies, which are only used at build-time, but are
obviously not needed at runtime (just like packages built with
autotools, CMake or meson also don't require them at runtime).

However! Of course the dependency trees of build tools and the built
software itself *do overlap* (this is the fact the Java Modularity
approach is ignoring). A lot of Java packages are used both as runtime
dependencies for build tools *and* as runtime dependencies for
applications (which is apparently outside the scope of Red Hat ???) ,
so those have to be maintained as non-modular packages anyway,
apparently as a community-only effort.

Fabio
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux