Maybe it would be useful to create some meta-subpackages, ala koji-builder-imagefactory, koji-builder-yum, which will encapsulate those optional dependencies? Would it be more transparent?

po 13. 5. 2019 v 23:14 odesílatel Neal Gompa <ngompa13@gmail.com> napsal:
On Mon, May 13, 2019 at 4:06 PM John Florian <jflorian@doubledog.org> wrote:
>
> I'm starting to wonder where the better value is: sticking closer to upstream or preserving the imagefactory functionality (in this particular case).  I haven't diligently kept notes, but it seems that whenever I deploy kojid on a newer Fedora release there is always trouble in getting things working.  Installing yum, which wasn't a Requires got me to where simple buildArch tasks would succeed but livemedia tasks aren't working because of similar missing Requires on pycdio and python2-kickstart.
>
> To be clear, I'm not faulting anybody's decisions.  I'm just having more troubles with Koji packaging than most things on offer in Fedora.  Maybe that's just the nature of something that is so flexible where many features are considered optional.  Mix in a little py2->py3 evolution and it's even more of a dark and twisty path.
>

Until the dilemma with imagefactory is resolved, my suggestion is to
build the upstream Koji spec and use that. It'll use Python 3 by
default on Fedora 30+. In Mageia 7, Koji is also fully Python 3, since
we don't have to care about imagefactory there.


--
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
koji-devel mailing list -- koji-devel@lists.fedorahosted.org
To unsubscribe send an email to koji-devel-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahosted.org


--

            Tomas Kopecek <tkopecek@redhat.com>
            Release Engineering Development, RedHat