On Tue, 19 Oct 2021 at 01:22, Andrew C Aitchison <andrew(a)aitchison.me.uk> 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(a)aitchison.me.uk
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproj...
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.