Learn more about these different git repos.
Other Git URLs
fedpkg chain-build has some issues nowadays, because we don't just let everything into Rawhide any more. We have gating tests!
fedpkg chain-build
@jskarvad tried to build tcl and tk using fedpkg chain-build today. It didn't go so well, because tcl is on the critical path. So after the tcl build ran and Bodhi automatically created an update for it, openQA tested it, and all the tests failed because openQA - correctly - detected that the update broke tk's dependencies. This prevented the tcl update going stable, so the chain build never reached tk, and now jskarvad is stuck with a broken tcl update (to get around this we had to waive the tcl test failures so it would go stable, then do the tk build, then we'll have to run the tests on the tcl update again after tk is stable to verify there are no other issues).
What fedpkg chain-build should really do these days is:
This would have a lot of advantages. Obviously it would avoid the above problem happening when a package in the chain is in the critical path or has gating CI tests. But it would also make it easier for packagers to Do The Right Thing with multi-package updates - we currently tell them, in the package update guide and other places, to do the above process manually, which is a bit of a drag. And it would make it possible to use fedpkg chain-build on non-Rawhide releases, which was requested years ago in https://pagure.io/fedpkg/issue/59 - exactly the same process should work for all releases, using side tags, I believe.
I noticed you can actually use fedpkg chain-build --target to chain build on a side tag already. so we have all the bits for this. I'd just advocate making it create a side tag and use that as the default target, and require you to pass --target=rawhide to do a direct chain build for rawhide.
fedpkg chain-build --target
--target=rawhide
It would be great if it could work this way even for non-rawhide, e.g. --target=f40. This could save a lot of time.
well, as proposed it would work kinda automatically - the side tag flow is effectively identical on all branches, so assuming it automatically created the side tag for whatever release the current branch represents (the same way request-side-tag does), unless I'm missing something, it should "just work" whatever branch you're on.
request-side-tag
I have been using chain-build together with --target for some time. But I admit these steps are ridiculous. For simple cases as for my bind+bind-dyndb-ldap, automatic side-tag creation for chain-build would be great. For unstable releases it might even auto-create bodhi update after finished successfully, unless told otherwise.
First manually requesting side tag, then copy&pasting the same tag (made by the same tool!) into chain-build, is just wasting developer's time. Of course more complicated rebuilds might need a lot of dependencies. But I expect most of chains are up to 5 dependencies.
Log in to comment on this ticket.