On 2024-06-25 13:33, Arthur Zamarin wrote:
So, are you ready for seeing the mess? Here we go.

Thanks Arthur, I can add some input as another AT.

======== 32-bit arches ========

This includes stable arches x86, arm, ppc, sparc32, dev arches s390, and
maybe more. Those are in much worse situation, with a mess on various
fronts, some of them super hard to continue support. For example
qtwebengine is less and less likely to manage to compile on a
real-hardware, and not 32-bit chroot on 64-bit host. Arch Team want to
minimize our work on those arches, meaning mass-destable and even
mass-dekeyword, with potentially full drop of stable status.

I think all of these need to be moved to dev. Particular attention on ppc because somebody seems to have gone on a rampage throwing keywords at it and so I frequently see packages with things like KEYWORDS="amd64 ppc" which makes no sense.

Also, hppa is 32-bit as well. The hardware is 64-bit, and so is the kernel, but the userspace is 32-bit.

sparc32 and s390 I think need to be dropped or exp at least. For the former we need to get sys-boot/silo out of tree. Also, in https://wiki.gentoo.org/wiki/Handbook:Main_Page#SPARC_Handbook we specifically call out:
In Gentoo, only SPARC64-compatible CPUs are supported.

======== ppc64 ========

Stable 64-bit arch. So, this is a mess of an arch. Consists of both
ppc64ul (big-endian) and ppc64le (little-endian). The latter is much
better supported by upstream. The profiles inheritance inside is a mess
(we even added running 32 userspace on 64 bit kernel, called ppc64/32ul
- just why?). We have devboxes for both BE and LE, so mostly fine. The
profile inheritance is the messiest I've even seen.

I would hope to split this arch into the two endianness, but I suspect
nobody has the energy to do it. Oh well.

Next proposal is to cleanup profiles: remove the ppc64/32ul, cleanup
profile inheritance, cleanup the masks and unmasks, and continue with
both ppc64ul & ppc64le supported.

Agree that this needs to be split. I could do the profile reorganization, but would need a developer who would be able to in one shot replace all KEYWORDS with both entries.

======== hppa ========

Sigh. Stable 64-bit arch. Out main Gentoo devbox died, and the second
one is always stuck compiling gcc for stage3 (a compilation takes 7
days). Here we have a fight in Arch Team. I prefer to destable it, Sam
prefers to stable it. This one is tough.

FWIW as the one handling these for now I also would prefer destable. I would say that any wd40 profiles should be ineligible for stable.

======== ia64 ========

Dev 64-bit arch. Kernel dropped support, glibc dropped support, devbox
died - days are short before full exp status or full removal of arch.

I would prefer to see this go straight from dev to removed. Also, a timeline on removal with respect to kernel/glibc EOL would be nice so that it doesn't just stay up in the air indefinitely. Our python deprecation schedule is a model of clarity.

======== alpha ========

Exp arch, with nearly (or maybe already) full correct dep-tree. matoro
did a lot of great work here, so I think we should promote it to dev
arch, so dep-tree remains unbroken. We dekeyworded a lot of stuff,
cleaned it up, so a nice "completion bonus".

Yes, this has been basically fully-correct for months now and it's very annoying to play catch-up constantly. Please make this dev at the soonest opportunity.

Also, current tree correctness is stuck on this: https://github.com/gentoo/gentoo/pull/36711

======== mips ========

Exp arch, with mostly good dep-tree. Does mips team want to make it dev
arch?

Unfortunately this is in much worse state than alpha. For a long while it was stuck on rust but luckily we now have rust and llvm, so I should be able to make more progress on it, but it's slow going. Dekeywording efforts would be hugely appreciated here.

Reply via email to