On Mon, May 16, 2022 at 09:13:32PM +0200, Jiri Vanek wrote: > Hello! > My apologies, I had accidentally dropped out of computer world for a while, and here a world spins ahead! Thanx a lot for many valuable feedback! > see the clarifications of most concerns: This mail appears to have copied in quoted text from many differnt messages in this thread, with no attribution of the author. This is very confusing and disruptive for following the conversation :-( Ideally please reply inline to the original mails. > > I cannot see how Fedora RPM packages for OpenJDK can redistributing pre-built binaries would ever be considered acceptable. > no, no and no again, Please see the linked https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs > In long run, we will build in koji once, and repack this to all live fedoras. There alre already prcednets, and even worse things - like packing blobish binary driver, are here. If we consider Fedora koji tag inheritance, to a limited degree we do implicitly already have the ability to build once and have it deployed on multiple Fedora versions. It just only applies to Fedora versions that arrive after the original build. eg if you built a package in Rawhide today, and never rebuilt it again for the next year, the one binary RPM would end up shipped to users in Fedora 37, 38 and 39. To some extent this does happen - on my Fedora 36 install, I've got about 40 packages with an fc35 dist-tag in the RPM release, and 2 with an fc34 dist-tag. In practice the mass rebuilds happen frequently enough to kill off inheritance across releases for most packages. Then for any non-trivial app there is usually a need for bug fix releases, which again kill off the inheritance. The point is that, AFAICT, there's no hard Fedora rule that forbids us having one binary RPM build shipped to multiple Fedora relases. (Or if there is such a rule, we're not enforcing it). It is just the practicalities of mass rebuilds and bug fix releases that mean it ends up being quite an exceptional case to share binaries across releases. Lets say we have a single JDK build that was done in Fedora 35 a year ago, and thus now present in F35, F36 & F37-rawhide. If a bug fix is needed, we can't simply build in current F35 build roots, since they include all subsequent F35 updates. We have a record of all the packages there were in the original F35 rawhide build root though. It would conceptually be viable to populate a build root with that original deps set, do a bug fix build, and tag that result into all subsequent releases. We don't have a way to actually put that into practice, which I guess motivates some of the re-packaging hoops the JDK proposal is wanting to jump through. Perhaps we can come up with a more supportable way to achieve this goal instead. NB, I'm assuming the shared libs that JDK depends on don't do ELF soname changes. I presume this is where the desire for static linking starts to come into play. Again static linking is not something totally excluded by Fedora - it just requires a good justification to be made > > 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....Detecting bugs early in both applications and GCC toolchain, > via builds in rawhide... > > Right you are, and it is already described in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Rawhide_GCC > We are very well aware of this benefit, and we will do our best to keep it running - eg to build portbales also in rawhide, although not to repack them. Just for this single - but huge - case. > We deeply agree with your description of rawhide and gcc bumps. Thanx a lot for highligting it. I wonder if it is possible to have the best of both worlds with two streams. What if new major JDKs were *only* added to rawhide, not existing releases. IOW, Fedora 35 would be frozen with the set of JDK major versions that existed at time of F35 branching off rawhide. Thereafter it only gets bug fix releases of existing major versions. In addition the certification is only done for the initial new major version build in rawhide, not subsequent bug fix builds. This would let the main Fedora JDK packages be fairly normal in terms of maintenence approach, and reduce the JDK certification process burden. Separate from that, have a module stream for portable JDK. The module build root populated with the oldest current Fedora stable release, minus any updates. Builds can be done static linked, and the module results made available to all Fedora streams. Every bug fix build goes through ceritfication, and adding new JDK major versions doesnt have combinatorial expansion of certification. Of course the obvious problem here is how to explain to users which JDK they should be preferring. If we just tell people to always use the portable version, then having the "regular" distro strweam version is kinda pointless and vica-verca. 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
