Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enable single build being update for several OSes #5387

Open
judovana opened this issue Jun 19, 2023 · 6 comments
Open

enable single build being update for several OSes #5387

judovana opened this issue Jun 19, 2023 · 6 comments
Labels
Discussion Issues that may be controversial and warrant a discussion

Comments

@judovana
Copy link

shmi package in Fedora, is built (once), then sent for signing, and then sent back to fedora. There is severe dance with tagging to make this package available in all live fedoras.
Now, also all javas in fedora are trying to do the same. Build once and ship everywhere. It is 5 more packages requiring being build once, and shipped everywhere.

Part of the https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere is to investigate ways, how to do all this tag dancing more simple and generally better.

One of th solutions is to enhance bodhi, that it woudl eb able to take one build, and make it update for several OSes. Is that even clsoe to be possible?

@mattiaverga mattiaverga added the Discussion Issues that may be controversial and warrant a discussion label Jun 20, 2023
@mattiaverga
Copy link
Contributor

It's not possible ATM, it would require a heavy rewrite of the code, starting from the database structure (every build is now related to a single release) and going through how bodhi determine what release a build nvr belongs to and determine when a build is signed for a specific release and adjust all consumers to not rely only on build nvr, but also look at the build tags to determine what update/release the message is related...

shim is a special case, it is released through bodhi only for one release, then releng manually tags it in other releases.

@judovana
Copy link
Author

Thanx for quick reply!
The part of the exercise is to allow also shim to not need relengs during each update.

For java-x-openjdks as in proposal, the workaround to "call relengs all the time" is to build portable tarball in weird way, and then repack it properly for each version. But the portables are lost in meantime, requiring rcm to tag them, or us, jdk maintainers, to build tem anyway.

Looking froward for the "Discussion", whatever that label means :)
TY!,
j

@mattiaverga
Copy link
Contributor

I've marked as "Discussion" because I have the suspect that the amount of work needed to modify existent bodhi logic for just a bunch of packages (we certainly don't want that everyone could push updates in such way for every package) is equal to have someone doing manual tagging for those builds for several years...
But maybe, if FESCO agreed on such workflow change, CPE folks can find a smarter and easier way that I cannot see.

@judovana
Copy link
Author

TY!

@skywalkersPadawan
Copy link

Is this issue still open I would like to work on this. I am new to these discussion type of issues is it only for discussing and giving a document fix for this one.

@judovana
Copy link
Author

Yes it is open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Issues that may be controversial and warrant a discussion
Projects
None yet
Development

No branches or pull requests

3 participants