This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------oINbLxALuvXay0owoCHDojkw
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

As you all know, Gentoo supports many various arches, in various degrees (stable, dev, exp). Let me explain those 3 statuses fast:

* stable arch - meaning we have stable profile for this arch, and stable keywords across base-system + varying degree of seriousness. We stable
stuff after ~30 days in tree, and are mostly happy. For example the well
known and common amd64 arch.

* dev arch - meaning we have complete dep-tree (no broken dep-trees),
but no stable profile. If you break here a package (for example
introduce new dep, previously unkeyworded) you are expected to dekeyword
and ask for rekeywording. For example the nearly unknown arch s390.

* exp arch - meaning we support what we support, with possible broken
dep-tree. This is the "scary" state of arch, since it can break at any
moment. For example the noisy (because of the physical fans) arch alpha.

So now that you know the arch statuses each arch can be, we have the
next mess - sub-arch profile. Did you know the ppc64 gentoo arch
consists of ppc64ul (big-endian) and ppc64le (little-endian), with the
latter having a much better support from upstreams. On sparc we have
both sparc32 (32-bit) and sparc64 (64-bit), with the former nearly not
working.

And the next important knowledge to know for this discussion is the
devbox situation. Arches that have a devbox (for example for sparc we
have catbus, a machine running sparc arch) are easier to maintain, since
we have the tattoo cluster (automated handler of arch stable/keyword
bugs), so it is simpler to maintain them. An unofficial requirement for
an arch to be stable arch, it should have a devbox.

Finally, many keywords on arches are continues because of inertia.
Someone added an arch 10-15 years ago, it collected dependencies, we
keyworded it, increase the dep tree, and the cycle continues. For a long
time the default keyword for new package was "~amd64 ~x86" - you see the point...

So, are you ready for seeing the mess? Here we go.

======== amd64 & arm64 ========

Stable Arches in the best state possible. We recommend people to stable
stuff for those arches, users have great experience with those, handling
on arch testing team is great and simple. No need to think on it.

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

--
Arthur Zamarin
arthurzam@gentoo.org
Gentoo Linux developer (Python, pkgcore stack, QA, Arch Teams, GURU)

--------------oINbLxALuvXay0owoCHDojkw--

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

iQEzBAEBCgAdFiEE/axFlFuH2ptjtO5EAqCvUD0SBQQFAmZ6/1EACgkQAqCvUD0S BQRA9gf+MD/v+9qer6uYiYVh2O1f9Y1ACOgmWdYwsiAAVE4tj4VLsiTNTcDOXlmG LdXyRsw2DgZMBnCBYWJei6Vgx3kNFE5e0SuQmCMHLjCKQgSEVIHahjcpqbYYlLtO vJBo5FwZYmdQeIIKzfIG1XfEDU9BJ+JI3JXdHCfceoV7C49Marf10AK00MyGpEKh e8sbohYDreltU6AQeiCOya36YDRSLd/E8AtoV96JYbN/L+EnISHYAXnhxiFMDCrH dzYsFRDGjG7om0cPcoxAJDc+Np7Cj5qDGrGy1dAT57xXIPZRwqr+otdJSFnya8LR GH1t+MAoJ0XnQTpsJK/op3/HoN6mVg==
=BTOk
-----END PGP SIGNATURE-----

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

Copy: arthurzam@gentoo.org (Arthur Zamarin)

As you all know, Gentoo supports many various arches, in various degrees (stable, dev, exp). Let me explain those 3 statuses fast:

* stable arch - meaning we have stable profile for this arch, and stable keywords across base-system + varying degree of seriousness. We stable
stuff after ~30 days in tree, and are mostly happy. For example the well known and common amd64 arch.

* dev arch - meaning we have complete dep-tree (no broken dep-trees),
but no stable profile. If you break here a package (for example
introduce new dep, previously unkeyworded) you are expected to dekeyword
and ask for rekeywording. For example the nearly unknown arch s390.

* exp arch - meaning we support what we support, with possible broken dep-tree. This is the "scary" state of arch, since it can break at any moment. For example the noisy (because of the physical fans) arch alpha.

This classification is good enough for practical purposes (and for the discussion of the status of architectures) but technically not correct.

I'll try to clarify below, but mostly to clean up confusion about wording.

You have to keep apart two things, A) architecture status, and B) profile status, which are formally independent of each other.

A) architecture status, defined in profiles/arches.desc

A.1) stable
amd64, arm, arm64, hppa, ppc, ppc64, sparc, x86
Architectures that have a stable keyword and where packages undergo stabilization.

A.2) transitional
(currently none)
Architectures that have a stable keyword and where packages undergo stabilization,
but the dependency tree is only consistent for ~arch.
This is useful for upgrading architectures to stable.

A.3) testing
all other
Architectures that only have testing, ~arch keywords

B) profile status, defined in profiles/profiles.desc

B.1) stable
The dependency tree is checked and enforced by the CI and by pkgcheck by default.
Unsatisfied dependencies etc generate errors and "break the tree".

B.2) dev
The dependency tree is checked by the CI and by pkgcheck (by default). Unsatisfied dependencies etc generate warnings.

B.3) exp
No checking (by default)

Many combinations of these two properties exist. For example,

amd64:
is A.1 and has many B.1 profiles (but also some B.2 and B.3)

loong:
is A.3 and has B.1, B.2, B.3 profiles

m68k:
is A.3 and has only B.3 profiles



--
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQKTBAABCgB9FiEE/Rnm0xsZLuTcY+rT3CsWIV7VQSoFAmZ8cDhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZE MTlFNkQzMUIxOTJFRTREQzYzRUFEM0RDMkIxNjIxNUVENTQxMkEACgkQ3CsWIV7V QSrPHQ//UvVuWgLm5zW5B7/ZmqLFWfQv2u1EEeA3aJhFYfqxyxG0w34buhqDDRBg UaP0EWUSFRzgwTvHpqaucw7w3tMrcg7ajkQGu3ZNeYcGvUyA/tsQChrekn9BYG2d y1XCfUmROsK/xFmI2wQURD8M46F0lu39BQL0sQNH8kg3XLx367rasR4socbav5Wk mfnScSMBommMmKPOTN+k/2DVyYHsyMdWl6FpFCPxEFBs5Ghk4mosps6NtzF5pjgi oPjR0S3mKD3GPnv2AumzXJfuatcF4FfTwextnxyk7Tama+CW97mtN1ZhQKimBrgk Wjtr4f3lY8gcQ+UH/3ndIUB73FCrxW9Jd2a6kE97P/YwcXPU09SekDArvZQogUJ8 yONlkkuFgNbJYKejqNpWDlWCeyA6tf0MLEGUNl2rDRWlHaph2qn9p3iCscKXkRFT q4Ut8IgJN+Zf0uVq1swW4ChcusHNxUpE/eHALin1BAXlJ9qBWc9I9duRLqovJ5sN vSgN8cBMola1OBbXgyX4b+VP5CFDKObUEFjfhG1vYQaWJ6IKFco2pRPVqP2pwPh5 Q2JxvatlldcHshWLxEZP5UYuDvILABTrdIYfLNsUbrKPsMK94VA8Wwz+

Copy: arthurzam@gentoo.org (Arthur Zamarin)

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

riscv is something new and growing, but for now hardware is still quite slow. We do not have any hardware devbox so far.

In its very beginning I proposed to use different keywords for 32bit and 64bit (if not for that, for what then???), but enthusiasm was limited.
** Reminder, people actually have to do the keywording and maybe stabilization, and more keywords means more work. **

If we split it, then please let's keep riscv for 64bit and e.g. use riscv32 and one day in the futre riscv128 for the other variants...

Also, this is a potential candidate for a future stable arch (i.e. having stable
keywords and stabilization).

--
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQKTBAABCgB9FiEE/Rnm0xsZLuTcY+rT3CsWIV7VQSoFAmZ8ePVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZE MTlFNkQzMUIxOTJFRTREQzYzRUFEM0RDMkIxNjIxNUVENTQxMkEACgkQ3CsWIV7V QSp2OBAAxt/7AAke+/waJ50CTkAFRBogdbnvGVZxx/+TB2eP2yNFJvIiXb+v4ab2 ZS9ZDQ/3Dj1o3J330SzzGk8RiS7pvR747yRCIjG0g5ghrVArydFIAmaWtrl0rlID U9Q7UnG55pwkVmNfGXu0u0kZ2Je1e0whmGEh/7dDy9XO/s4BSiM90Z++U6fo1/S9 v8joQZ4HtXBn0/y+jBRZcpgXQ5OywBraSeNNi15BfGAaAQSflUycYYqpukASILG5 e9oLJtSp6ci19U6xAxWyiAiF98oAO0W/5aRZ+JxIgL6ivAG88os3IrxDIwxPXRUU d72s6CU11ajw1em4Os7bH6VPghsmIwIr4RnAMXm6mvyyGuwcsJ0b+w39212UzN+K xxmJdQo51KuVFmhAD4m3L+S6xB5QcXndhQDVjJ8R6WHSfWf09YLKj0/YbO/scCX0 887tYyXA2fS1jZfhT/mvadADjjVKHGevqQwz0A9W2xU2sGItjJGuNBtjDpBs/EEL +LSI0LXW8y0JhDJZMCovq866MdfPE1ssugmpClvzte0W7jq5rPy366qxWK2Oq+QG 9zrZyEI7V8CDP/To8futw1QDs+GuVYVl1AMdA1RojIkmKXZcCMFjOoGX

Copy: arthurzam@gentoo.org (Arthur Zamarin)

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

We've got several different types of problems here.

1) Different data type sizes
This is the least problematic point, since testing in a chroot works fine.

2) Limitations, e.g. limited memory address space
Also not that problematic, since testing in a chroot on a 64bit kernel circumvents the limitation somewhat.
Whether it makes sense to be able to build something in a chroot but never
on real hardware is another question.

3) time64
This is work in progress. I guess we'll get it done until 2038.

4) isa- and hardware-related regressions.
This is the real problem that cannot be caught via chroots and testing
on fast 64bit machines...
We recently had an upstream regression in glibc that (from memory) broke
all machines without SSE. It took a surprisingly long time for anyone to
notice that, since of course any x86-64 machine understands these instructions. The only way to really reproduce it on modern hardware is
in qemu-system with disabled kvm.
Can we call an architecture "stable" if we never test on real (and not "downward-emulated") hardware?

--
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQKTBAABCgB9FiEE/Rnm0xsZLuTcY+rT3CsWIV7VQSoFAmZ8gz9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZE MTlFNkQzMUIxOTJFRTREQzYzRUFEM0RDMkIxNjIxNUVENTQxMkEACgkQ3CsWIV7V QSp9tRAAlONrXmlwrKJ1Ir3/hwM67WE6DEqKVy+N6DS3LYll8ObHXD3BUZrJ1nkR JcaoTUqiScXHtzw1PNGlo/RRtGUMHhff3ufIm6slt/BmmJfgcFuf5Wyb0n+1KaCt nYMdl9SBqecQ2RFRXEkBqCyNpvIqoZ8VdZ3YTmLa84pHcUbY/SdCoK+XRuV3shw9 /+KYheUW8p/hAFbbhAOoaBVn6ZkPRs9Tq12YFxHOYx8xAHUCbKlmv5Xo3lWBrdaa mDLsONOgkBymxScqlhvMHarFJRPq4eJYo6rc4qik4eKOS+PYnsn2uUj0fI3jpIyN e1+4eaZLONXewB7rhUJ/F3eR/g5WRCREn1pNcwCInGwFz9ZkVV1VSxcz27bL654I JXQz1l1O9QTg/ZPK4yAHFT86oIRkHktwGjBk0cqO4KDaUCdqXgM5zE6VL1FEou1I L4RIPFeKKPaPCN5uZEwcFmfAod8eDYbxoI3fIs9Gg2zatabHIe5eEse2ly1zRat7 wGk5EPIrcqv/ngB1ZO224qhb2YkTjZbRT95uwI7cap760PAdweZrs9o4tuCAcMAC jgYlYTzqnGE/BaELDqy0h7olB0SJ2zZixUuqx6dd13C7JyO7hXDD/Ssy

Copy: arthurzam@gentoo.org (Arthur Zamarin)

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

[...]

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.

So, technically, splitting a keyword into two is easy to do.

You start with duplicating the KEYWORDS entry in all ebuilds, and duplicating the
profiles. Then both profiles and keywords are pruned where it makes sense,
and they develop independently.

Happy to help with this part as it's mostly mechanical.

The really important part however is what comes afterwards: Separate keywords mean
* separate keywording requests
* separate stable requests
and there should be at least some sort of arch team taking care of that.


--
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQKTBAABCgB9FiEE/Rnm0xsZLuTcY+rT3CsWIV7VQSoFAmZ+4QlfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZE MTlFNkQzMUIxOTJFRTREQzYzRUFEM0RDMkIxNjIxNUVENTQxMkEACgkQ3CsWIV7V QSpIfg//fqRkk7lL1n56H65L/9Z4hCzLJW3EGPHrdgFqnlySNVjlhvlPkjwan8Yn TDeafb2lzenrzkONUTGawepdAC7JzAYBpr6P18XE0JBrQCqb7GglZAaH0V3xLXSJ azUMRhT96v6L8SnB2UTnv4lyckA00zX0ZfniXDNhZx3T/OSVz5itklXYHIROI5Lm WmqztRuUg8egCDV09GeeuQHragloQ5fSS/raEKZ/2FZFT4uH93+CSOATMQkhukJZ KIwxuFRyXmwo/3CyGiCjo03agPHiuukXi8CSytzYvllVMJCho6jdZ71n9yHrvAWc VmoLXNrKaQzlWOKEzNOyoOMQFGLQI1smdetulNtFcQgb2dK6Nv+QI/831EOw+E+y u0CmyF1TPRlMRmOdg+rTBdsnUeqvX11+JvJ7FTklXr34ILsG1jNDx5fOtDknwYQu 7AoKa1PMkJPZOY94Zc/D1Pb2fNrkHKSiT0UIEu7Yhg/k4GsQvcsLvE7QFh8itl4H gmkX3+18MR+sG33RBSOEeXaGGpuWepYlEtqKkLcZJuQPWg9rMRoQeAQVqNsXqGjc ZPpmxwj3SMCV+zhj7rs7fqEKM2U6So2n6fEvCLErY/d5EGWS1p0uMeSO