Apologies if something similar already exists or has been discussed
before. If so, I'd appreciate being pointed to the relevant
documentation or discussion.
I'd like to propose an alternative that may complement raising
architecture baselines. Instead of increasing the default baseline for
official binary packages, Debian could make it easier for users to
locally rebuild the distribution with CPU-specific optimization flags
(mostly march, -flto , -fstack-protector-strong etc ). The idea is to
extend APT/dpkg so it can automatically rebuild installed packages and
their dependency graph from source. While the required pieces already
exist, coordinating recursive builds currently requires managing
custom build scripts and manual intervention. Integrating this
workflow into APT would make optimized local builds accessible to
ordinary users without requiring packaging bootstrapping expertise.
A possible workflow could be:
1. Install a minimal Debian system.
2. Enable an optional "source-based package management" mode that:
* configures source repositories,
* installs the compiler toolchain and build dependencies,
* allows user-defined or Debian-recommended compiler flags.
3. Rebuild installed packages (e.g. `apt reinstall '~i'`), with APT
automatically resolving build dependencies, rebuilding packages from
source, and reinstalling them.
4. Continue using the same mechanism for future
`upgrade`/`full-upgrade` operations.
Potential benefits:
* No need for managing multiple micro-architectures
* No major space requirements
* Server all variety of users (scientific computing, security focused etc)
* Will this reduce efforts in bootstrapping ?
A few anticipated concerns:
* Why not implement this as an external script?
Most of the required functionality already exists. However,
integrating the workflow into APT would provide a more consistent user
experience, reduce duplicated tooling, and make the feature accessible
to a broader audience instead of only advanced users.
* Why not simply use a source-based distribution?
Source-based distributions certainly provide this capability, but
Debian's strengths are different: long-term stability, well-maintained
packaging, conservative updates, and extensive security support. I
value those and still want the option to optimize packages for my own
hardware.
* Would this increase unsupported bug reports due to custom compiler flags?
That is a legitimate concern. One possible approach would be to
provide a small number of supported optimization profiles (or simply
default to the distribution's standard flags), while clearly
documenting that bug reports resulting from unsupported compiler flags
should first be reproduced using the supported configuration before
being reported.
I realize this would represent a significant enhancement to APT and
would require careful design. Nevertheless, it seems like a possible
way to satisfy users who want hardware-specific optimization without
requiring Debian to change the default architecture baseline for
everyone.
Regards,
Vipul
> On Oct 26, 2025, at 5:40 AM, Bastian Blank <[email protected]> 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.
>
