Re: Architecture baseline for Forky
Why not support power 8 beyond 2028? It is still a good system and supports newer little endian. Hopefully, you can reconsider and keep power 8 for as long as power 9/10 regarding baseline support.
> On Oct 26, 2025, at 5:40 AM, Bastian Blank <waldi@debian.org> wrote:
>
> Hi
>
> We never did a real discussion about architecture baselines before, but I think
> we should do that. We also don't have any guidelines what we as Debian want to
> actually support. But given that we are a general purpose distribution, we
> have to find a balance.
>
> As a general guidance I would like to aim for a ten to 15 years support range
> at release time. The cutoff in respect to the expected 2027 release date of
> Forky would therefor be 2012 to 2017. More time is given for widely used
> architectures, less for more specialized ones.
>
> Bastian
>
> # Current architecture baseline
>
> Only three architectures set an explicit baseline in gcc-12 (Bookworm) and
> gcc-15 (Forky):
> * armhf: armv7-a+fp
> * i386: i686
> * s390: z196
>
> All other architectures use the default values.
>
> # Proposal for architecture baseline
>
> ## amd64 (and i386)
>
> * x86-64-v2: Supported since around 2008[^x86]. Used in RedHat 9[^redhat9x86].
> * x86-64-v3: Supported since around 2013-2015[^x86]. Used in RedHat
> 10[^redhat10].
>
> I propose to use the x86-64-v2 baseline in Forky. It gives us more then the 15
> years and everyone else already switched to it or even a newer variant.
> Factoring in a possible LTS for Trixie, this means that x86-64-v1 will stop
> being supported by Debian in 2030.
>
> ## ppc64el
>
> * POWER8: Launched in 2014[^power8].
> * POWER9: Launched in 2017[^power9]. Used in RedHat 9[^redhat9] and
> 10[^redhat10].
>
> I propose to use the POWER9 baseline in Forky. The Debian infrastructure seems
> to be comprised of all POWER9s. This means POWER8 will stop being supported in
> 2028.
>
> ## s390x
>
> * z14: Launched in 2017[^z14]. Used by RedHat 10[^redhat10].
> * z15: Launched in 2019[^z15]. Used by next Ubuntu.
>
> I propose to use the z15 baseline in Forky. Yes, this is less then ten years,
> but s390 is such a niche architecture and all we do is best (often not even
> this) effort support. The Debian infrastructure is documented to be at least
> z15, all accesible system are actually z16. This means that z14 and older will
> stop being support in 2028.
>
> # How to see supported baseline
>
> The dynamic linker of glibc can show what microarchiture level it considers
> supported on the current CPU. The "supported" marker is relevant in this case.
>
> ## amd64
> ```
> % /usr/lib64/ld-linux-x86-64.so.2 --help | sed -n '/^Subdirectories of glibc-hwcaps/,$p'
> Subdirectories of glibc-hwcaps directories, in priority order:
> x86-64-v4
> x86-64-v3 (supported, searched)
> x86-64-v2 (supported, searched)
> ```
>
> ## ppc64el
> ```
> % /usr/lib64/ld64.so.2 --help | sed -n '/^Subdirectories of glibc-hwcaps/,$p'
> Subdirectories of glibc-hwcaps directories, in priority order:
> power10
> power9 (supported, searched)
> ```
>
> ## s390x
> ```
> % /usr/lib/ld64.so.1 --help | sed -n '/^Subdirectories of glibc-hwcaps/,/^ z15/p'
> Subdirectories of glibc-hwcaps directories, in priority order:
> z16 (supported, searched)
> z15 (supported, searched)
> ```
>
> [^power8]: https://en.wikipedia.org/wiki/POWER8
> [^power9]: https://en.wikipedia.org/wiki/POWER9
> [^x86]: https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
> [^z14]: https://en.wikipedia.org/wiki/IBM_z14_(microprocessor)
> [^z15]: https://en.wikipedia.org/wiki/IBM_z15_(microprocessor)
> [^redhat9]: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/9.0_release_notes/architectures
> [^redhat9x86]: https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level
> [^redhat10]: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/considerations_in_adopting_rhel_10/architectures
>
> --
> Spock: The odds of surviving another attack are 13562190123 to 1, Captain.
>
Reply to: