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.
Thinking about this some:
package A (release 1) has two dependencies B and C.
A-2 is built in side-tag #1 for B'
A-3 is built in side-tag #2 for C'
Case #1
-------
Side-tag #2 is merged, A-3 is in rawhide for C'.
Side-tag #1 is asked to be merged:
- A-2 < A-3, so "uprade path" is not ok
-> Merge is blocked, a new build A-4 is required
A-4 is built against B' and C'
--> all good
Case #2
-------
Side-tag #1 is merged, A-2 is in rawhide for B'.
Side-tag #2 is asked to be merged:
- A-3 > A-2, so "upgrade path" is ok
-> Merge is ok, but A-3 was built against C', not B'
Solutions:
- Do not allow one package to be in two side-tags at the same time?
- Ensure the tests for Case #2 would prevent the merge (doable?)
- 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?
Pierre