>> We are planning to change the way Alternate Architectures (non x86_64) >> are handled >> in terms of "primary" vs "secondary". The definition of what is >> primary or secondary >> is already handled more in terms of the build artifact outputs (images, LiveCDs, >> installers, containers etc) for i686 deliverables. As part of this redefinition >> this means that the location in "koji instances" of the rpm builds is removed as >> a part of the definition requirement of what constitutes >> primary/secondary and the >> architectures are named "Alternate Architectures" (and Experimental >> architectures >> for the likes of MIPs/RISC-V) as opposed to primary/secondary. As a >> result of this >> change it is planned to merge the old "secondary" koji instances into a single >> koji instance along with all the current "Primary" architectures. >> >> All the details of the proposal along with FAQ have been put on a wiki >> page here[1] >> so please go and read it and ask any questions that aren't answered in >> the FAQ here. > > I do have serious concerns about the impact of this in terms of build > failures. Reading the reply to " Q: Why do I have to worry about > s390x/powerpc/aarch64 when I didn't before?", it implies there will be > no change to koji in terms of build failures: i.e. a failure on *any* > arch will cause the entire build to be failed. There will be a slight change that a failure in an arch won't cancel the other arches and each one will run to completion (pass/fail) but the overall primary task will still fail. > The answer...honestly does not convince me. I think the result will be > a combination both of an increase in failed builds and the issues > caused by them, and an increase in the number of packages which simply > disable building on an arch entirely due to a lack of will to deal with > build issues (and/or slow build time) on that arch. The data we have for build failures across all the arches show that not to be the case. All the pure noarch packages, which is over 50% of the distribution, currently can and are regularly built on ppc64/ppc64le builders now anyway due to them being in primary koji for EPEL so for a large percentage it's already dealing with a lot of the arches we're due to cover anyway and there's not been a single issue reported there in the 12 months that ppc64le has been present. And in response to the "slow built times" the builders in the non primary koji instance are of equivalent or faster than the x86 builders. EG the ppc64 builders use to be a LOT slower than x86 back when we had Power6 builders, but that hasn't been the case for over 3 years, and the current Power8 generation builders are actually faster than the x86 builders. For ARMv7 (which is not part of this because it's already in primary) will actually get faster builders on aarch64 as part of this change. > With secondary koji instances, neither of these are major issues, and > secondary arch teams are able to work on build fixes for those arches > without the maintainers being bothered by them. In most cases the maintainers are still bothered by failures even from the secondary arches anyway, it will certainly be more up front to them but the core packages that historically have issues (toolchains etc) already have maintainers that actively test and support the non x86 architectures anyway. > Has any consideration been given to the possibility of increasing > Koji's flexibility here, by allowing for arches to be designated as > non-fatal, so a package build failure on that arch would not cause the > task to be considered a failure? Yes, but how would you deal with a soname bump where if it's not fatal on an arch what happens when something is then rebuilt against one version on one arch and a different version on a different arch. You end up in a big mess really quickly. It ends up being a lot less work (even in the current situation with non x86 arches) if the issue is fixed from the outset. Peter -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
