On Tue, Nov 25, 2025 at 5:10 PM Simo Sorce <[email protected]> wrote: > > 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 ? >
That's true, but one other goal is that I'd like to instantly know how many times a package has been rebuilt without changes. It can be handy to get an at-a-glance idea of how much its dependencies influence it. Something that gets rebuilt 10 times between source changes over a 6 month period probably warrants a deeper look in its dependencies than something that only gets rebuilt 2 times in that same timespan. Of course, we don't *have* to do that, but I'd like to try, because I have found it useful when working through stuff in openSUSE (where this data is available) and when I built packages as my day job on a private Open Build Service instance. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ 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
