I found the point where the solver was being misconfigured, but fixing that revealed a further issue whereby the generated modules aren't taking the "bootstrap" build environment into account: https://src.fedoraproject.org/modules/bootstrap/blob/master/f/bootstrap.yaml

While that will be useful eventually (once we start trying to replace that module with properly defined modules for the various developer tools), for right now, we just want fedmod to consider it as a potential build dependency, even though it's not included in the published module metadata.

One complication here is that the bootstrap modulemd is missing the artifact list normally generated by MBS, and since it isn't built in MBS, I'm not aware of such a file actually existing anywhere. (@ralph @karsten, am I right about that?)

For now, I'll just emulate it by assuming that every RPM built from the SRPMs listed in the bootstrap module will be available for installation in the build root.

One complication here is that the bootstrap modulemd is missing the artifact list normally generated by MBS, and since it isn't built in MBS, I'm not aware of such a file actually existing anywhere. (@ralph @karsten, am I right about that?)

For now, I've just emulated it by assuming that every RPM built from the SRPMs listed in the bootstrap module will be available for installation in the build root.

Merged PR using that approach: https://pagure.io/modularity/fedmod/pull-request/21

This is to the point now where I'm not sure which is right when fedmod claims that the official module definition for something like MariaDB is leaving a lot of its build dependencies implicit - BuildRequires on the mariadb SRPM brings in a lot of stuff.