tor 2021-09-23 klockan 11:29 +0200 skrev Miro Hrončok: > > However, I think side-tags should be the preferred solution, as their > impact is > isolated. Buildroot overrides create temporary broken dependencies > for > everybody, while side-tags don't. For stable releases I think I agree, even when there is just one dependent package that have to be rebuilt as is in my case. But would help with a little automation in fedpkg to reduce the amount if information that have to be bounced via the package maintainer * remember per fedora release that there is a side-tag created and make "fedpkg update" submit the side-tag and not the individual package. For example by storing them as .side-tag-<release> file in the working tree. * Use that info in "fedpkg" automatic target selection to avoid needing to manually specify --target to build. * allow a depends-on package tree to be specified at fedpkg build time in dependent packages to automate finding the correct target like above. * fedpkg update likewise should detect the side-tag and submit the side-tag as the update and remove the now obsolete .side-tag-<release> file There is a little inconsistency in that the package git trees will reflect the side tags, but seems total overkill to enforce the use of git branches for build side-tags. For rawhide it adds yet another step to the process (submitting the update). But on the other hand it's good to have similar process as for stable branches in how to build dependent pacakgers so no worries. > And than instead of describing the details, link to > https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/ The only objections there is that a) It's name kind of implies that side-tags then only is about rawhide, which isn't really the case. b) The page still says "We are working on this workflow and will update this page and send an announcement when it is ready or available for testing" at the top, kind of saying that one should not yet follow what the page says. Regards Henrik _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
