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