On 03/12/2018 09:35 AM, Pierre-Yves Chibon wrote: > On Mon, Mar 12, 2018 at 03:58:13PM +0100, Kevin Kofler wrote: >> Pierre-Yves Chibon wrote: >>> Do note that the uniqueness constraint that koji has will mitigate things >>> there. For a package to be built for -liba and then -libb, the package >>> will need to have its release field bumped twice. >> >> Sure, but that has not prevented conflicts in the past either, because it >> does not ensure that the second bump is actually built against the new >> library for which the first bump was committed. > ...snip... > > Solutions: > - Do not allow one package to be in two side-tags at the same time? I think this would be difficult... > - Ensure the tests for Case #2 would prevent the merge (doable?) Yeah, that might be nice. In fact if it's a library so change it would easy because there would be broken deps. > - Figure out if between build and side-tag merge-request one of the package in > that side tags has been part of another side-tag (definitely doable, "just" a > little more logic) > - Another idea? I think these cases are rare and also that maintainers should communicate, so they should be detected. Notifications of builds and/or commits should definitely tell a maintainer that two people are rebuilding things in two side tags. Perhaps when creating a side tag we could display the existing ones so you know if what you are trying to do might overlap with an existing one? For that we might need a short description of the side tag... f29-kevin-xfce "Side tag to build the Xfce stack" or f29-exampleuser-boost "Side tag to rebuild against new boost x.y.z" kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
