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
