|This is a solution looking for a problem. Either that or it’s woefully incomplete. All this does is fetch the sources for each of your installed packages and builds them. It doesn’t recurse (easy enough to add) and it doesn’t handle failures. (Any mirror that’s down can break the script).
Mostly it doesn’t actually give you anything different than the auto-built binary .deps. We’d have to write a gnarly little gcc wrapper to add/replace machine/processor optimatization switches (for what you seem to be asking about) and we’d probably find that many of the resultant packages failed to build or had subtle bugs as a result of inappropriate CPU optimizations.
To make an “Optimized” Debian maintainable we’d want to work with the maintainers and have a switch or hook that allowed the build host to run a “configure” script and generate a base set of compiler flags. This is a gross oversimplification since Debian has C, C++, Objective-C, and many other sorts of source code; and most of this discussion only relates to C/C++
A question then becomes: what other “aspects” could be separated from the packages and managed by the builder? (I’m referring, vaguely, to AOP, aspect oriented programming, here). Back to my initial comment: What is/are the problem(s) to
which this is (part of) a solution?
BTW: my script also fails if it encounters a
build-dep that points to a virtual package; like
the kernel-headers-2.4 (virt)package which is supplied by one of the more specific kernel-headers-2.4.18-xxx-smp or similar real packages.