From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (unknown [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 6AA7415802E for ; Tue, 25 Jun 2024 17:33:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A887AE2A7D; Tue, 25 Jun 2024 17:33:22 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 396FFE2A69 for ; Tue, 25 Jun 2024 17:33:22 +0000 (UTC) Message-ID: <75654daa-c5fc-45c8-a104-fae43b9ca490@gentoo.org> Date: Tue, 25 Jun 2024 20:33:05 +0300 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US From: Arthur Zamarin To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Arch Status and Future Plans Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------0AEhHrC0teCSx5VRPkqbYnkr" X-Archives-Salt: bdc3f0f3-fa43-4e3d-8298-437a112b6b4c X-Archives-Hash: ad84df102119f507dfd539ecb757ca58 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------0AEhHrC0teCSx5VRPkqbYnkr Content-Type: multipart/mixed; boundary="------------oINbLxALuvXay0owoCHDojkw"; protected-headers="v1" From: Arthur Zamarin To: gentoo-dev@lists.gentoo.org Message-ID: <75654daa-c5fc-45c8-a104-fae43b9ca490@gentoo.org> Subject: Arch Status and Future Plans --------------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. =3D=3D=3D=3D=3D=3D=3D=3D amd64 & arm64 =3D=3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D 32-bit arches =3D=3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D x86 =3D=3D=3D=3D=3D=3D=3D=3D 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). =3D=3D=3D=3D=3D=3D=3D=3D arm =3D=3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D ppc =3D=3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D ppc64 =3D=3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D sparc =3D=3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D hppa =3D=3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D ia64 =3D=3D=3D=3D=3D=3D=3D=3D Dev 64-bit arch. Kernel dropped support, glibc dropped support, devbox died - days are short before full exp status or full removal of arch. =3D=3D=3D=3D=3D=3D=3D=3D s390 =3D=3D=3D=3D=3D=3D=3D=3D 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). =3D=3D=3D=3D=3D=3D=3D=3D loong =3D=3D=3D=3D=3D=3D=3D=3D Dev arch. I have no info on it, but it works. Let's not touch :) =3D=3D=3D=3D=3D=3D=3D=3D riscv =3D=3D=3D=3D=3D=3D=3D=3D 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= =2E =3D=3D=3D=3D=3D=3D=3D=3D alpha =3D=3D=3D=3D=3D=3D=3D=3D 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". =3D=3D=3D=3D=3D=3D=3D=3D m68 =3D=3D=3D=3D=3D=3D=3D=3D Exp arch, works ? maybe? I've no idea. Let's not touch :) =3D=3D=3D=3D=3D=3D=3D=3D mips =3D=3D=3D=3D=3D=3D=3D=3D Exp arch, with mostly good dep-tree. Does mips team want to make it dev arch? --=20 Arthur Zamarin arthurzam@gentoo.org Gentoo Linux developer (Python, pkgcore stack, QA, Arch Teams, GURU) --------------oINbLxALuvXay0owoCHDojkw-- --------------0AEhHrC0teCSx5VRPkqbYnkr Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----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----- --------------0AEhHrC0teCSx5VRPkqbYnkr--