On Thu, Jun 1, 2023 at 3:45 AM Kevin Kofler via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Aoife Moloney wrote: > > As described in > > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; > > during last year, packaging of JDKs had changed dramatically. As > > described in same wiki page, and individual sub changes and devel > > threads, with primary reason this - to lower maintenance and still > > keep fedora java friendly. > > And these changes have made the Fedora Java packages basically useless, > because there is really no advantage anymore to be had over just using, > e.g., Adoptium builds. Your changes have removed the choice from users to > choose between a Java built the upstream way (Adoptium and others) and a > Java built according to the Fedora Packaging Guidelines as all Fedora > packages are supposed to be (but yours no longer are). > > > * In first system wide change, we had changed JDKs to build properly > > as standalone, portable jdk - the wey JDK is supposed to be built. I > > repeat, we spent ten years by patching JDK to become properly dynamic > > against system libs, and all patches went usptream, but it become > > fight which can not be win > > This is already against the best practices recommended by the Fedora > Packaging Guidelines, and arguably even against a mandatory rule (because > you say all the patches allowing unbundling went upstream): > > https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/ > > "All packages whose upstreams allow them to be built against system > libraries must be built against system libraries." > > > * as a second step we introduced portable rpms, which do not have any > > system integration, only builds JDK and pack final tarball in RPM for > > free use. > > * In third step - without any noise, just verified with fesco - > > https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully > > integrated rpms. Instead of this, normal RPMS BUildRequire portable > > rpms and just unpack it, and repack it. > > In short, you build an RPM containing a tarball instead of unpacked files, > and then have the final RPM BR that intermediate RPM, untar the tarball, and > repackage it. A really ugly hack that goes against any packaging best > practices and maybe even subtly violates the letter of the Fedora Packaging > Guidelines (it is definitely against the spirit). > > I do not understand why FESCo approved this hackery. It brings no advantages > whatsoever to the user, it just makes the builds take longer overall for no > good reason. > We approved it because realistically we'd rather have *some* advantages of it being built by Fedora rather than none at all. Because the alternative is no Java runtime at all, and that's even less acceptable. We're going to have to figure out how to ensure Fedora Java benefits from new compilers and new build environment customizations, but at least we're going to have OpenJDK in Fedora at all. Keep in mind that this isn't exactly the first time we've done this either: the .NET runtime is similarly screwy for its bootstrap process, and that's split across a couple of source packages. At this point, we hold our noses and hope for the best. At least there's a chance to reduce the pain with .NET over time as the Red Hat .NET folks work to improve upstream. There's basically zero chance for improvement with OpenJDK because of the nature of the upstream and how old and crufty they are. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
