Re: Architecture baseline for Forky

On 7/25/26 15:55, Vipul Goel wrote:
> 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.

This sounds interesting, and intersects with one of my longstanding todo 
items (trying to bootstrap musl-based debian ports). Long ago Erik 
Andersen made a uclibc-based debian image, and I've never been able to 
reproduce that with musl-libc...

> A possible workflow could be:
> 1. Install a minimal Debian system.

I would love it if there was a definition of that part I could build by 
hand, to get to the point where the debian plumbing could build 
additional packages (and rebuild those base packages under a provided 
chroot).

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

Pushing built packages into a repo would be nice.

Getting a packages-to-build dependency list so I could send them to VM 
instances to build in parallel would be nice. (If the nodes are using a 
network mounted root filesystem I can have a base server install 
packages that all the VMs then see...)

> Potential benefits:
>      * Will this reduce efforts in bootstrapping ?

Dunno, but I'm happy to test anything you've got...

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

My problem was the "already exists" requires a lot of domain expertise I 
don't have, and reading through debootstrap/rebootstrap to try to 
reverse engineer it was a bit dense.

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

Did you know that gentoo lists every single target a package supports in 
every single package's ebuild file? When qualcomm tried to bootstrap 
"hexagon" support using gentoo, they wound up telling it that hexagon is 
an i386 variant just so they didn't have to touch every single file in 
the tree.

Years ago I bootstrapped a minimal native development environment that 
booted under qemu (with distcc calling out to the cross compiler running 
on the host's loopback so I could get about -j3 builds) then had a 
target-agnostic Linux From Scratch build run in that system.

It's all obsolete now, but I've still got that somewhere...

https://landley.net/aboriginal/control-images/

https://github.com/landley/control-images/tree/master/images/lfs-bootstrap

Alas moving on from there to natively bootstrapping gentoo was 
nigh-impossible because every architecture was entirely bespoke and 
special case and you could NOT just go "here's a compiler with libc, 
build your packages" without exactly describing the Known Existing 
Variant already hardwired into the ebuild tree.

https://github.com/landley/control-images/tree/master/images/gentoo-bootstrap

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

I can ping people with domain expertise in low level embedded system 
integration, but the debian domain experts have always been too busy to 
handhold me through "baby's first debian image built entirely from 
source"...

The set of targets I'm currently regression testing are:

https://landley.net/bin/mkroot/latest/

And I've got both cross and native compilers for all that:

https://landley.net/bin/toolchains/19-06-2026/

Rob