On Mon, Mar 12, 2018 at 12:44:39PM -0700, Kevin Fenzi wrote: > 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. Actually even the changelog entry should be enough to "communicate" this: When I see "- rebuilt for foo-n", it's pretty obvious that I need to make sure to include foo-n in my build environment. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
