Bootstrap minutes at Emdebian Sprint
Discussions were had about bootstrapping in Debian during Emdebian Sprint 2011. The following things are as close as I (Jonny Austin) could record to what was agreed, it probably needs to be merged with various specs already describing these things.
New name for bootstrapping dependencies
Avoid using X-Build-dependsN to avoid a transition later. This might be useful if backporting bootstrap patches to existing distros.
Bootstrap1 comes before Bootstrap2. We can add an arbitrary number on top. Once package is done, -Bootstrap' goes away.
Testsuite - clearly necessary for making sure people keep bugs out. Run daily/weekly/monthly and report things that mean cycles are no longer automatically broken. Generate report to say 'packages stuck in bootstrap mode'. If we don't use a stage, eg stage4, we log that it wasn't used (we don't need to report this, but make the information available)
If a bootstrap Stage N build fails, we log that as a FTBFS.
We should provide tools to help people realise they are in a cycle. Perhaps generate a list of packages in cycles on a daily basis.
Patches to wanna-build and sbuild to work nicely with this (for native building)
We don't need Build-Depends-build and BuildDepends-host, as multiarch solves this issue for us.
When building a bootstrap stage it should go into a separate archive (to avoid package name clashes, ensure no contamination of real archive with bootstrap packages)
Loops must be manually broken by human intervention to add bootstrap information to control files for loopy packages. Once this has been done we want tools that automatically traverse the dependency tree (with the new dimension) and manage bootstrapping
- - this tool should keep track of all packages that were built while a bootstrap version of any of their dependencies was being used, so they can be rebuilt when the 'non bootstrap' version is available.
We should agree on a subset of the archive we want bootstrappable before we move further. The consensus was that we should start with 'essential' and 'required' and the closed set of their build dependencies. We believe this will give us a system that a) boots and b) will be able to build anything else natively.
The tools will traverse the tree in a reliable way. For now, we're happy with 'always take the lowest package in an alphabetical sort'. Note that tracking everything build against a 'bootstrapN' package and rebuilding against a real package once one becomes available is essential to ensure that we always get 'Debian' at the end. Also note that the changes required for bootstrapping sometimes change ABI which can have a ripple-on effect.
Some concrete goals:
0. Prove this works in some situations. Show the world our solution. 1. Get a manual scripty builds working 1.5 Start with 'something green' - IE we want to say "these work, we can break the loops but we can't break out" - show the world. 1.6 Keep graph of progress - percentage of pkgs that can be bootstrapped - "name and encourage" packages in large loops 2. Get a reporting system so that we make package maintainers aware that they are part of a cycle breaking problem