<contyk> mprahl: so I was talking to merlinm about epel8/epel8-playground and stream expansion
<contyk> the idea is we would like Fedora modules to expand against both of those buildroots without modifications to the modulemd files (which would make poeple opt in into epel in practice)
<contyk> but both epel8 and epel8 playground need to have runtime dep on platform:el8
<contyk> I don't think this is currently possible; I was wondering if we could expand the platform definitions some more, possibly including something like "if you expand against me, use this stream as a runtime dependency instead of my stream name"
<contyk> do you think that would be reasonable? would that be too complicated? would it affect some compatibility checks we have in place?
<mprahl> contyk: I think that would cause issues with dependency resolution because if you build module A that buildrequires platform:epel8 and B:foo, then B:foo would require el8, which wouldn't match epel8. I'd have to check the MBS code to verify this though. If we used KojiResolver, then it wouldn't matter. The available modules to build against would be based on what's in a tag.
<merlinm> mprahl: I'm pretty sure contyk meant the platform streams used by epel8 and epel8 playground (eg., "el8" and "el8_playground").
<mprahl> merlinm: I don't understand the question then. :P
<merlinm> mprahl: well, when the el8 and el8_playground virtual platform streams are deployed (as they are in staging)...
<merlinm> simply letting stream expansion do it's thing when a modulemd file has buildrequires: [] and requires: []
<merlinm> results in modules getting build that require and buildrequire platform:el8_playground
<merlinm> that doesn't play nice with the standard set of provided modules, or with dnf
<merlinm> everything is expecting runtime requires of platform:el8
<merlinm> does that make more sense?
<contyk> mprahl: but don't we do the same thing internally with those x.y.z buildroots?
<contyk> mprahl: the playground platform could still provide :el8 or something
<contyk> unless that code expects that versioned string
<mprahl> contyk and merlinm: Do you mind filing a ticket? I or one of the MBS developers can try experimenting with it.