ppc64 has a terrible hack where they have a selection of p7 optimised binaries. One example of this is python3. We some how get python3-3.5.1-7.fc24.ppc64.rpm and python3-3.5.1-7.fc24.ppc64p7.rpm but only the ppc64p7 variants of python3-libs and all the other sub packages as can be seen here:
https://dl.fedoraproject.org/pub/fedora-secondary/development/24/Everything/ppc64le/os/Packages/p/
I'm not sure if we're using dnf for the pungi process but I suspect if we are this might be part of the issue
Dnf is not involved in any way. Yum is used currently. Daniel has a branch with port to DNF.
From what I gathered so far: the repo with all the packages has python3-libs for both ppc64 and ppc64p7. Config for depsolving does not have any specific requirements on that package.
python3-libs
ppc64
ppc64p7
Log of the depsolving shows it found python3-libs.ppc64p7 only. The version for ppc64 is not mentioned at all.
python3-libs.ppc64p7
For some reason the package must be getting excluded in pungi/gather.py. Looking at the code, since greedy method is set to build, yum picks what it thinks is the best package.
pungi/gather.py
build
If I change the greedy method to all, it will include both arches. There will likely be other extra packages, though. The config option for this is greedy_method.
all
greedy_method
Is this still an issue? Looking at the latest Rawhide and branched composes, there are no packages with ppc64p7 arch anymore.
Metadata Update from @lsedlar: - Issue close_status updated to: Insufficient data - Issue status updated to: Closed (was: Open)
For reference: We killed off the ppc64p7 sub arch. It was a terrible hack, wasn't well supported in dnf (or in general). In the future the optimisations will be done using IFUNC in glibc/gcc.
This issue has been migrated to Fedora Forge: https://forge.fedoraproject.org/pungi/pungi/issues/233
Please continue any further discussion there.