On Tue, 19 Oct 2021 at 01:22, Andrew C Aitchison <andrew@xxxxxxxxxxxxxxx> wrote: > > On Thu, 7 Oct 2021, Stephen John Smoogen wrote: > > Things have probably improved, but the lesson I learned from EPEL-8 > > and afterwords was that koji depsolving is weird no matter how set up. > > Koji sets up mock environments in a way that will do fine as long as > > there are NO modules in the repositories it is looking at. Once a > > module, even a non-default module, is there things start to go wonky > > because the way that koji depsolves will say that > > 'foobaz-3.10.1-3+module' is a better solution than > > 'foobax-3.9.4.<arch>' it will then try to pull that in and boom you > > end up with broken builds. You can change the method that koji chooses > > packages to be in the buildroot, but the other option ends up trying > > to insert things like foobax-3.9.4-i386 into an x86_64 or still does > > the modular change but chooses foobar-2 due to some depsolv quirk. > > Is the foobar/foobaz/foobax intended or are they typos ? > If they are intended, then I think we have a partially ordered set of > packages, ie it isn't always possible to say whether a > b or a < b. > > Without knowing anything about koji, I'd say that whilst > foobaz and foobax can provide foobar (and perhaps foobar==3) > they cannot satisfy foobar>=3.9 (unless they are forks or > reimplementations of foobar-3.9). > In the case I was remembering they were forks and say inside them that they satisfy anything >= 3.9. Normally you would only have one in a buildroot but you could have alternatives in modules because they each fixed something specific to that module. If you tried to install both modules you would get conflicts so only one module was to be installed at a time.. However, Koji doesn't know that.. one solution method only knows NEVR, Provides and Requires and another tries to use a bit of dnf to do resolutions but that seemed to act weirdly also. In the case where they are all foobar but say foobar-4.0 or foobar4 is in a non-default module, then koji and dnf might come again to different conclusions of what is needed to be in the buildroot. The only mental solution I could come up with was that there would need to be some tool to put all modules (and bare rpms dependent on them) into a RHEL-modularity tree and somehow import that into MBS so that it could deal with them. That would then allow for both EPEL modules to depend on them, and keep them out of the way for koji regular builds. The major problems with that was a) no perl/python/ruby/etc in non-modular builds (all that would be available is platform-python) b) it would break Fedora build system in ways because it assumes what is in its toolkit was built by it and we are faking these. In any case, it is a conundrum wrapped up in an enigma surrounded by a puzzle. > -- > Andrew C. Aitchison Kendal, UK > andrew@xxxxxxxxxxxxxxx > _______________________________________________ > epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to epel-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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on a BBS... time to shutdown -h now. _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
