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
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
