Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

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

 



On Wed, May 11, 2022 at 12:58:22AM +0200, Fabio Valentini wrote:
> On Tue, May 10, 2022 at 11:51 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
> >
> > On Tue, May 10, 2022 at 5:20 PM Robert Relyea <rrelyea@xxxxxxxxxx> wrote:
> > >
> > > On 5/10/22 6:29 AM, Ben Cotton wrote:
> > > > https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
> > > >
> > > > This document represents a proposed Change. As part of the Changes
> > > > process, proposals are publicly announced in order to receive
> > > > community feedback. This proposal will only be implemented if approved
> > > > by the Fedora Engineering Steering Committee.
> > > >
> > > > == Summary ==
> > > > This is initial step to move JDKs to be more like other JDKs, to build
> > > > proper transferable images, and to lower certification burden of each
> > > > binary. Long storyshort, first step in:
> > > > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> > > >
> > > > This first step will move, one by one, individual JDKs in F37 to be
> > > > built `--with-stdc++lib=static` and against in-tree (bundeld)
> > > > libraries:  `--with-zlib="bundled"  --with-freetype="bundled"
> > > > --with-libjpeg="bundled"  --with-giflib="bundled"
> > > > --withlibpng="bundled"  --with-lcms="bundled"
> > > > --with-harfbuzz="bundled" `
> > > >
> > > > We already made a heavy testing of the behavior, and user should not
> > > > face negative experience. I'm not sure if this is
> > >
> > > I'm very confused on why this reduces certification burden. In our
> > > crypto libraries this is exactly the kind of behavior we would *NOT*
> > > want packages to do because it increases our certification and support
> > > burden.
> > >
> >
> > I'm confused how this would not negatively impact the user experience,
> > because things like FreeType and HarfBuzz in Fedora have features and
> > configuration that are non-default that improve the font rendering
> > capabilities of applications that link to FreeType. I would rather
> > have our shared maintenance and evolution of font stuff be reused in
> > Java too...
> 
> I agree, I don't think there's positives for the user experience here.
> And I don't understand what actual problem this change is trying to
> solve?
> Are people really installing OpenJDK RPM packages, taking the
> "/usr/bin/java" binary, and putting it onto some other system?
> Unless that's really the case (and I don't think that should even ever
> be supported for distro packages), I don't see a reason to change how
> we build OpenJDK.

When the change talks about being "portable", my understanding is that
means within the context of Fedora. eg they want to be able to build the
JDK version in a Fedora 35 build root once, and then ship that built
binary in Fedora 35, Fedora 36 and Fedora rawhide (37) by just tagging
the F35 build into the newer Fedora koji tags too, instead of rebuilding
for each Fedora version.

> Also, I am particularly concerned with this statement from the linked
> follow-up change:
> "After this change is in air, we will certificate each binary only
> once, and redistribute."
> I cannot see how Fedora RPM packages for OpenJDK can redistributing
> pre-built binaries would ever be considered acceptable.

Normally when we talk about forbidding pre-built binaries, it is
because said binaries were built by a 3rd party into whose build
system Fdora has no visibility. This case appears different in
that Fedora is still building the binaries in one release stream,
but these pre-built binarijes are then copied into another
releases stream. Thus Fedora would still have visibility into the
build process, albeit in a rather convoluted  way, compared to
normally maintained package.

One downside with building in F35 and then re-tagging into newer
Fedora releases, is that we loose any insight into problems coming
down the pipe. Currently a Fedora rawhide mass rebuild will often
highlight pre-existing bugs in applications, and/or highlight bugs
in newly rebased GCC toolchain.

If the JDK is only really being built in the oldest stable Fedora
release, then we loose this early detection of problems. If a GCC
rebase has a bug that impacts JDK, we'd potentially only discover
it many many months later once that rawhide becomes the oldest
stable Fedora release, and an attempt is made to build new JDK.

Detecting bugs early in both applications and GCC toolchain, via
builds in rawhide is a really critical aspect of our dev model.
IME rawhide is the place where it is cheapest to fix problems &
least disruptive to our users, because we have time to find and
fix issues before they get into release.

Yes, it is tedious for package maintainers when their specific
app breaks in rawhide due to a toolchain regression, but it is
a win for Fedora as a whole to find these problems quickly.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
_______________________________________________
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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[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