V Mon, Dec 20, 2021 at 10:39:11AM -0500, Stephen John Smoogen napsal(a):
You can configure koji to do a slightly different depsolving using dnf versus the koji algorithms, which fix things in that only default modules may get enabled in mock. [However may is a strong word.. it sometimes does not.]
The fixes to this are: a) use a tool like grobisplitter which breaks out all modules into separate repositories versus 'virtual repositories'. This allows koji and mock better ability to sort out what is the right package to put into the buildroot. b) use a script program like ursa major which basically hardwires in MBS determinations. This works for EL8/EL9 because the changes in modules has to go through a lot of internal checklists and such to make sure the script is updated and doesn't break in builds. It doesn't work that well in Fedora unless we put in similar 'please mark this package as to be used for this and get a PR signoff' [or someone writes and maintains a tool to do this which they did in MBS...] c) everything which uses a module, requires to be a module. Then MBS does all this determination and tells koji -> I don't care what you think, tag in Module-B's golang-foobar for this build. d) someone replaces koji with a build system which knows about MBS and other meta-tools.
Koji uses Mock for building packages. Mock allows enabling modules. Users can define their own build roots using side-tags (*). There are only two missing pieces to allow building non-modular packages with modules: Allow side-tags to pass the enabled modules to Mock, and make composes in Koji modular. Then all the installation magic around modules would be heavy lifted by DNF.
* That reminds that actually users can do it manually even now: If they tag a modular go compiler into their side-tag, they simply get it installed as a build dependency for any package built in the side tag.
-- Petr