On 2024-01-25 17:10, Russ Allbery wrote:
Rebuilding a bunch of software after a security fix is not a completely
intractable problem that we have no idea how to even approach. It's
just
CPU cycles and good metadata plus ensuring that our software can be
rebuilt, something that we already promise. Some aspects of making
this
work will doubtless be *annoying*, but it doesn't seem outside of our
capabilities as a project.
One worry I'd have is that we have - in the past - been very
conservative in what we rebuilt. We have not rebuilt the archive
pre-release either (maybe we should!). So you are suddenly rebuilding
binaries with a new toolchain and updated inputs - and while it's easy
to review source diffs, there are always some unknowns what is happening
to the binary as a result. From a(n ex) release perspective that would
be my main worry.
I agree that the rebuilds themselves are a matter of programming,
assuming they succeed and you don't need to do them in stages to resolve
dependencies. Presumably we'd then need a pipeline to publish partial
security updates as the leaves of the tree complete (or enough of a
heads-up). If you have stages because intermediate builds incorporate
bits of other packages and re-export them into build environments
(unlikely?) or if you need to shepherd a lot of failed builds and try to
debug what happened, then it becomes a lot more toilsome and
labor-intensive.
Kind regards
Philipp Kern
