On Tue, 2025-11-25 at 15:46 -0500, Neal Gompa wrote: > On Tue, Nov 25, 2025 at 3:42 PM Florian Weimer <[email protected]> wrote: > > > > * Florian Weimer: > > > > > * Neal Gompa: > > > > > > > On Tue, Nov 25, 2025 at 12:01 PM Vít Ondruch <[email protected]> > > > > wrote: > > > > > > > > > > > > > > > Dne 25. 11. 25 v 15:58 Zbigniew Jędrzejewski-Szmek napsal(a): > > > > > > #3501 Adding %buildrelease macro to DistTag to open the door for > > > > > > automated rebuilds > > > > > > https://pagure.io/fesco/issue/3501 > > > > > > ACCEPTED (+4, 0, 0) > > > > > > > > > > > > > > > Will we benefit from this next mass rebuild? 🤔 > > > > > > > > > > > > > No. It is going to take time to flesh out an implementation in Koji > > > > that we can use. > > > > > > We can extra data from the Git history and store it in %_sourcedir, > > > just using RPM macros. No Koji changes are required. > > > > Ah, presumably you want to avoid the Git commits. > > > > Just increment %buildrelease globally once per mass rebuild then. 8-) > > > > We're trying to avoid the potential for build collisions and update > collisions caused by no-change rebuilds. And ultimately we want every > single submission of the same Git commit to result in a unique build. > This is aimed to make things like Go and Rust compiler upgrades, > FFmpeg upgrades, and required reverse dependency rebuilds to not > require colliding git commit pushes. > > It eliminates one of the major needs for a proven packager because > Koji doesn't block builds to packagers. Proven Packagers would then > only be needed for builds that require source changes. > > This means using %buildrelease in your manner would defeat that entirely.
Can't this simply be resolved by adding some sort of timestamp to the release number on build ? Each build of the same git commit would then have a different, but time-ordered, build version. of course foobar-1.2.3-1.202511251708.fc44 does not look as appealing as foobar-1.2.3-1.<smallernumber>.fc44 but it works and is simple ? Simo. -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
