I humbly request to split OpenJDK build and integration, in purpose to make another step in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs Note, that indeed no change of built will be done - that was done as part of https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic .
Currently, we ship java-XY-openjdk-V-R.fcAB.arch packages (xy={8,11,17,19}). The jdk is built and packed during build. Now, the jdk will be built in java-XY-openjdk-portable-V-R.fcAB.arch package, which will pack only tarball(s) in the package(s). java-XY-openjdk-V-R.fcAB.arch will BuildRequire java-XY-openjdk-portable-V-R.fcAB.arch and will only unpack the tarball, and repack it to the subpackages 100% identical to current ones and add integration (alternatives, scriplets, system configs)
I'm intentionally using notation ...fcAB to highlight, that this is not "build once, ship everywhere". Each jdk will be built in its Fedora version, and repacked in the same one. The "build once, ship everywhere" from https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs will be done as separate, system wide change once this (if ever) this portable repack woks as it should.
There are several reasons to allow this - it is a necessary prerequisite to the final (if ever) attempt of build once, ship everywhere - the existence of portbale tarballs shipping fedora-tested jdk withotu any integration is beneficial - the integration and build are of nearly same lenght (1000+ lines each). To split the build and integration to its own package will heavily lower the maintanenace burden - jdk is supposed to be distributed as tarball. For many usecases, the tarball may be better then well integrated rpm - the final rpms will remain identical. - the rpm integration tunraround will go down ffrom days, to hours - testing will be able able, if needed, to properly split integration and heavy functional testing
Note, that we have now proceeded with jdk17: https://koji.fedoraproject.org/koji/packageinfo?packageID=36382
Other portable versions are under review.
Exactly what kind of exception do you seek from FESCo?
Not exactly sure to be honest. The rule is that everything to be built form sources. I do, but indirectly. If you think I do not need any exception, feel free to close. I thought it is better to ask rather then doing unwillingly harm to java or fedora.
To me, this tastes and smells a lot like "repackaging binary blobs", and the only way that this is kind of okay is because the tarball you use comes from something that's BuildRequires'd (i.e. a package that was built on + for Fedora) instead from an external Source file ... so this might be "technically" OK, but I'm not sure weather it sets a bad precedent.
The only place where this is even somewhat potentially allowed currently is with bootloaders, and that's mostly because we ignore that it doesn't follow policy... (if we pretend problems don't exist, do they go away? :weary: )
This feels weird to me.
the rpm integration tunraround will go down ffrom days, to hours
I'm not sure how this is true?
I agree that this is bad precedent, which should not be followed. Yes, technically I'm ok, but I do not want to create this precedent, hence asking for exception. So there is at least good precedent for asking. You are correct with "something that's BuildRequires'd (i.e. a package that was built on + for Fedora)" statment for sure.
The java rpms integration is not simple, and bugs appear. Similarly, build of jdk is not simple. And is lenghty. (6hours +).
if we mess up integration, the fix - build-test-deploy or return to fix, will go down to minutes, because we skip the build, which was done in java-xyz-portable, which we jsut BR. With the build, it is something you do, then start koji build, and then return it to it tomorrow morning.
Generally the maintaneace and qa cost of java rpms will be lightened a lot by this step.
I think this should be an exception from FPC.
I think everything is fine here. The main point is that "The rule is that everything to be built form sources.". This is satisfied. In the end we have a build that is a) fully under our control, b) starts from sources and ends in some set of binaries. The fact that in the middle we use an rpm to store the intermediate stage doesn't impact users. It is possible that this is more work for the maintainers, but if the maintainers think this is helpful, then there is no reason to block this.
If you think I do not need any exception, feel free to close. I thought it is better to ask rather then doing unwillingly harm to java or fedora.
Thank you. I don't think we need an exception. Instead, I would like FESCo to confirm that this is approach is considered OK.
The only place where this is even somewhat potentially allowed currently is with bootloaders, and that's mostly because we ignore that it doesn't follow policy...
I don't think they don't "follow policy", at least in this regard. The policy says [1]:
This is a requirement for the following reasons: Security: Pre-packaged program binaries and program libraries not built from the source code could contain parts that are malicious, dangerous, or just broken. Also, these are functionally impossible to patch. Compiler Flags: Pre-packaged program binaries and program libraries not built from the source code were probably not compiled with standard Fedora compiler flags for security and optimization.
The stuff that is being discussed here doesn't cause either of those problems.
In fact, there are other cases where we build something and then repackage it into another binary rpm: static libraries. We discourage them because it's a lot of maintenance work to rebuild things, but I don't think anybody considers it against the policy for package sources.
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries
I agree with everything @zbyszek said above.
With my FESCo hat on, I agree that the intent of the rules are being followed. So I'm +1 in favor of letting them move ahead with this approach.
Thanx a lot for all hints in this thread.
What should be done with this ticket?
I would like to close the ticket as ACCEPTED, in line with my proposal above.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DC5D7TOTAYLQYJVY6XNFCKL57HZ3XS57/
https://meetbot.fedoraproject.org/fedora-meeting/2023-01-03/fesco.2023-01-03-17.01.html
Metadata Update from @churchyard: - Issue close_status updated to: Invalid - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.