= phenomenon = the ppc secondary arch team dropped 32 bit support earlier in the year when they added ppc64le support. The urden and cost of 32 bit was deemed to be too high. they have not supported 32 bit installs since Fedora 18 due to lack of community interest and help in testing. When ppc32 was dropped a few people complained and said they wanted to pick it up and support it still. There has been no work to date. There was an email to the ppc list last week with an introduction from someone wanting to work on it https://lists.fedoraproject.org/pipermail/ppc/2014-August/002943.html the task is really too big for one person, I know from having tried to maintain an arch by myself in the past.
= background analysis = Due to the way koji works its not feasible to ever add 32 bit ppc back to ppc.koji.fedoraproject.org as it would completely nullify the effort to remove it due to maintenance costs. it owuld need to be its own koji, tertiary arch support has been thrown around as a name.
= implementation recommendation = FESCo should recommend if and how ppc32 should be supported, noting that it will set precedence for the future if other arches drop support, say s390 dropping 31 bit support.
Replying to [ticket:1336 ausil]:
= implementation recommendation = FESCo should recommend if and how ppc32 should be supported, Are you asking FESCo to make a specific decision because you think it is the only one possible, or are there several reasonably valid options that FESCo should collectively decide among? The above is explicitly not recommending anything, yet if FESCo is to decide without a recommendation, there is no much to base a decision on: Due to the way koji works its not feasible to ever add 32 bit ppc back to ppc.koji.fedoraproject.org as it would completely nullify the effort to remove it due to maintenance costs. Could you be more specific? This sounds like 32-bit buildroots can technically run on ppc64 (correct?), i.e. having the 32-bit packages available and used (and possibly failing all the time) would not prevent use of the buildroots for ppc64 (correct?) so what are the costs? Hardware availability? Updating arch-specific boot and compose tools?
= implementation recommendation = FESCo should recommend if and how ppc32 should be supported, Are you asking FESCo to make a specific decision because you think it is the only one possible, or are there several reasonably valid options that FESCo should collectively decide among? The above is explicitly not recommending anything, yet if FESCo is to decide without a recommendation, there is no much to base a decision on:
Due to the way koji works its not feasible to ever add 32 bit ppc back to ppc.koji.fedoraproject.org as it would completely nullify the effort to remove it due to maintenance costs. Could you be more specific? This sounds like 32-bit buildroots can technically run on ppc64 (correct?), i.e. having the 32-bit packages available and used (and possibly failing all the time) would not prevent use of the buildroots for ppc64 (correct?) so what are the costs? Hardware availability? Updating arch-specific boot and compose tools?
In particular: which parts of the effort, and costs, can / can’t be done by a someone else interested solely in ppc32, which parts must / must not be a shared burden between ppc32 and general rel-eng/infra? I.e. what are the options and requirements for a secondary ppc32, and what are the options and requirements for a tertiary ppc32?
And how would a “tertiary” ppc32 differ from a “secondary” ppc32? Wouldn’t we simply treat secondary ppc32 as a separate arch, the same way arm* is separate from ppc64?
Replying to [comment:3 mitr]:
Replying to [ticket:1336 ausil]: = implementation recommendation = FESCo should recommend if and how ppc32 should be supported, Are you asking FESCo to make a specific decision because you think it is the only one possible, or are there several reasonably valid options that FESCo should collectively decide among? The above is explicitly not recommending anything, yet if FESCo is to decide without a recommendation, there is no much to base a decision on: Due to the way koji works its not feasible to ever add 32 bit ppc back to ppc.koji.fedoraproject.org as it would completely nullify the effort to remove it due to maintenance costs. Could you be more specific? This sounds like 32-bit buildroots can technically run on ppc64 (correct?), i.e. having the 32-bit packages available and used (and possibly failing all the time) would not prevent use of the buildroots for ppc64 (correct?) so what are the costs? Hardware availability? Updating arch-specific boot and compose tools?
32-bit chroots can run on 64-bit machines. However, koji treats any arch in its list as something required to completely successfully. So in a single instance of koji, you cannot list both ppc and ppc64 as the arches and ignore ppc failures. It will also fail the ppc64 builds.
The other costs are maintenance of packages and testing, neither of which the ppc team is doing or wants to do, and the rel-eng side of things.
In particular: which parts of the effort, and costs, can / can’t be done by a someone else interested solely in ppc32, which parts must / must not be a shared burden between ppc32 and general rel-eng/infra? I.e. what are the options and requirements for a secondary ppc32, and what are the options and requirements for a tertiary ppc32? And how would a “tertiary” ppc32 differ from a “secondary” ppc32? Wouldn’t we simply treat secondary ppc32 as a separate arch, the same way arm* is separate from ppc64?
Yes, but arm, s390, and ppc* are all completely separate koji instances. All of them are currently secondary. Dennis is suggesting that if one wishes to continue with ppc32, they setup their own koji instance and drive it from their. That way ppc64/ppc64le builds would continue as they are today. "Tertiary" isn't technically a thing as ppc32 could just be viewed as another secondary arch. I think Dennis was mainly using it as a way to distinguish that it would be split entirely from the existing ppc efforts.
Replying to [ticket:1336 ausil]: = implementation recommendation = FESCo should recommend if and how ppc32 should be supported, Are you asking FESCo to make a specific decision because you think it is the only one possible, or are there several reasonably valid options that FESCo should collectively decide among? The above is explicitly not recommending anything, yet if FESCo is to decide without a recommendation, there is no much to base a decision on:
there are many valid possible ways to move forward here. I should just have removed implementation recommendation. I want FESCo to decide how things should be implemented. which could be its dead let it be, set it up as a separate arch, to it has to be done in the ppc koji (which would get massive resistance, its been a multi year effort to drop it)
Technically it can be done, it was for years. however if there is a build failure in ppc32 it would cause ppc64 and ppc64le to fail also. It comes down to the whole reason why we have secondary arches. we want to let people scratch thier itch but not have it hold back everything else. The costs are that fixing ppc32 issues to unblock ppc64 and ppc64le take significant time. it was a cost that the ppc team has decided to not have anymore.
They really need to provide a full set of infra, from builders/hub to large amounts of storage at least 4T of disk is needed. along with public ips, hosting of builders and hub machines,
i guess the difference comes down to how they follow builds, do they follow koji.fp.o or ppc.koji.fp.o there is possibly a higher chance that a build gone through ppc.koji will have ppc fixes applied but no guarantee that it will work. perhaps even 32.ppc.koji.fedoraproject.org as a hostname and not ppc32.koji.fedoraproject.org there is probably more questions than answers.
Probably the major difference is at the moment the current "secondary" koji platforms are all hosted by Fedora infra and hence things hosting and core storage is provided within the Fedora infra. "Tertiary" infra would need to provide all of that, so not just man power
"AGREED: any arch that wants to call itself fedora needs to build up and host their own infrastructure, along with building up enough packages to show that they can do a working remix of fedora. Then request that FESCo consider them as a secondary arch (+7,0,0) (nirik, 17:41:06)"
Login to comment on this ticket.