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