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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
