On Wed, Mar 13, 2019 at 11:59 AM Florian Weimer <fweimer(a)redhat.com> wrote:
* Mikolaj Izdebski:
> On Tue, Mar 12, 2019 at 4:42 PM Miroslav Suchý <msuchy(a)redhat.com> wrote:
>> Alternative sum up:
>> * People (not just Mikolaj) started using modules, while Koji cannot use modular
repos.
>
> Incorrect. Koji (the software) *can* use modular repos. I know of more
> than one installation of Koji that successfully builds non-modular
> contents against modules.
Which installation would that be? I would be surprised if there was
*any* module-capable version of Koji out there.
Private installations that are not accessible publicly. I run one of
them myself.
For example, is there a Koji version that can handle correctly the
case
where one module provides Python 2 subpackages of a source RPM, and
another module provides Python 3 subpackages from a source RPM of the
same name?
Yes, Koji can do that, since version 1.14.
As far as I understand it, under the Koji model, one of the tags
wins,
and which one determines whether you get the Python 2 subpackage or the
Python 3 subpackage. You cannot get both. You will need two or more
buildroots for that.
That used to be the case, but for some time Koji supports
"repo_include_all" option [1] that has the exact effect you describe -
when set it makes build repos include all tagged RPMs, even if they
come from different SRPMs that happen to have the same name.
[1]
https://pagure.io/koji/issue/588
--
Mikolaj