On Tue, Jan 21, 2025 at 09:22:37AM -0500, Neal Gompa wrote: > On Tue, Jan 21, 2025 at 9:14 AM Zbigniew Jędrzejewski-Szmek > <zbyszek@xxxxxxxxx> wrote: > > > > On Tue, Jan 21, 2025 at 02:09:51PM +0100, Fabio Valentini wrote: > > > Workflow with non-vendored dependencies: > > > - update library or backport fix > > > - submit rebuilds of dependent applications (with rpmautospec, those > > > are no-change commits) > > > > > > Workflow with vendored dependencies: > > > - check out application and vendored sources > > > - patch vendored sources > > > - repeat checkout / patching for *every affected application* > > > > > > Yes, Neal, making changes so that no-change rebuilds don't require git > > > commits would make workflow 1 even more streamlined. Waiting for your > > > proposal on how to achieve this ;) > > > > At the fundamental level, such automation would effectively do two > > steps: > > 1. create a no-change commit like we do now, > > 2. push the commit and fire off a build. > > > > (I think we want to keep 1. unchanged. We need to store the information > > why did the rebuild and why _somewhere_. Either we keep the current > > mechanism which works well and is easy for humans to interact with, > > or we store this information in some external database and create new > > tools to query this. I don't think we want to do this.) > > > > I think this is the fundamental disagreement we're going to have. I > think no-change rebuilds should be happening with such frequency that > the reasons just stop mattering. Git commits for no-change rebuilds > are the fundamental reason why we have so many provenpackagers. They > need to do it for the most banal things, the most common being > rebuilds when a dependency is upgraded and has a soname bump. Yes. In my worldview, this "no-change rebuild" is actually not a "no change" rebuild. We're talking about rebuilds after _important_ changes happened in the dependencies. In fact, we're doing the rebuild because *their API changed in an incompatible way*. But this also means that since the dependency we're rebuilding against had important changes, this potentially has important effect on the package being rebuilt. Maybe it FTBFS, or maybe it doesn't work anymore, or maybe its own API changes, causing the need for cascading rebuilds. In general, the correct solution to such things is to avoid them. People keep breaking compatibility and changing SONAMES and doing other things like it made them feel better. If we have the choice, we should pick higher-quality dependencies which are stable and don't require constant pointless churn. But if we are unlucky and depend on something that does require rebuilds, I want to have a name and an explanation attached to the rebuild. > And this causes us real workflow problems, such as update collisions. > Just recently, we had a problem reconciling GStreamer and Qt updates > because an intersection of packages had to be manually rebuild for > each update in a particular order. But that would not have been > necessary if no-change rebuilds were just automatically added to side > tags (also for single build updates to automatically be converted to > side tags updates for this purpose). > > If our buildsystem is doing the right thing, we will always have a > record of that information in Koji, regardless of Git. We can trace > through historical builds fairly easily. But I have never felt that > requiring commits for no-change rebuilds is worth the cost of making > everyone have to do manual toil. I think we must move in different areas of the distro. For me, the occasional cost of doing an empty commit and pushing that to a branch is unimportant compared to, for example, the problems of figuring out what to rebuild or dealing with constant stream of failed builds and flaky CI. Zbyszek -- _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
