Misc arch plans (Re: [gentoo-dev] Arch Status and Future Plans)

[Sam James <sam@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 5891 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]