Arthur Zamarin <arthurzam@gentoo.org> writes:

Hi all, this will be a long mail, and might be confusing, I'll try to organize it, but this is a mess, so bear with me.

[...]

======== 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.

======== x86 ========

Stable 32-bit arch. I'll be honest, I don't believe at all this should
be stable arch anymore. I propose making it dev arch, and mass-dekeyword stuff we got because of inertia. This arch is close to HW die. (let's
not talk about i486 vs i686).

We need to be clear on the rationale for making something a dev arch.

If we're going to mass-dekeyword, the need for it being a dev arch
lessens, no?

There's also the frustrating issue of keywords in general with regard to
"did this ever work" vs "we support it and want to keep it going", which
is why pruning keywords is a bit of a shame - though I think we should
do it. (It's annoying for stuff which actually imposes no new depgraph constraints and works fine, and creates work when something gains a dep
on it.)

======== arm ========

Stable 32-bit arch, split into many sub-arches, based on the arm
generation (4, 5, 6, 7, ...). We use a 32-bit chroot on arm64 host to
handle this arch. While not urgent since the host is strong, it is
already collecting tech debt.

I propose we mass-destable and mass-dekeyword stuff. Should still remain stable arch status.

Sounds OK, I think. I'd want "lightweight desktops" to have stable KWs
there (lxqt/xfce).

======== ppc ========

Stable 32-bit arch. Becoming harder and harder with time, with more
broken stuff (which I just destable/dekeyword).

I propose we convert it into dev arch status, not stable. If folks
disagree, once again mass-dekeyword.

I can't know if I disagree or not until we're clear on what the
rationale is for depgraph consistency.

dev arch status won't help here if mass-dekeywording is
*separate* because then we just get very noisy CI.

======== 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.

I'd like to see it split too but I don't want to do the work myself.

======== sparc ========

Stable 32-bit and 64-bit arch. Has the best devbox (just seeing all the
CPUs in htop is warming a Gentoo heart).

32-bit sparc is something which is being removed from the kernel, and
didn't really exist (?), so we can just clean it up and drop support for that.

Agreed.

64-bit sparc works quite well, with even rust support (what a
surprise!), and we should just cleanup keywords we got ebcause of
inertia. Don't be afraid to dekeyword and destable stuff (consult with
Arch Team), but nothing as mass work.

Agreed.

======== 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.

hppa is 32-bit right now. The userland work is stalled on glibc support.

I think I can live with it being ~arch after reflection, but I'll talk
about my feelings for ~arch vs stable in general for these arches in a minute.

======== 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.

Yeah, no interest in ia64, sorry. I'd like it to just go.

======== s390 ========

Dev arch. Has 2 sub-arches: s390 (32-bit) and s390x (64-bit). The latter works well for its job, a good devbox.

For s390 32-bit we want to drop the profile, to simplify the profile
mess it has (mask&unmasks) for packages that work for 64-bit (like all
the rust stuff) and 32-bit stuff (inherits wd40 profile).

Let's kill s390 (31-bit). s390x should stay.

======== loong ========

Dev arch. I have no info on it, but it works. Let's not touch :)

======== riscv ========

Dev arch. I don't have much info on it, but I heard some mess with
riscv32 and riscv64, so maybe time to split it? I leave it to riscv arch team, which works quite well, but I'll be happy to open discussion for it.

I still think we should split the keywords.

======== 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".

OK.

======== m68 ========

Exp arch, works ? maybe? I've no idea. Let's not touch :)

Me neither.

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

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

No idea from my end.

-----BEGIN PGP SIGNATURE-----

iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZntdY18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZC/fwD/YHdJntsiXMTgAc0z8XFA5LE5lTqdpfymYNkY c3hmwicA/iiXPO2a1JvNE0E+A8E2KbXdZqG/ALbsLXML1s49dUcG
=BSp3
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)