TEXT   31

arm m automated bootstrap

Guest on 28th May 2022 03:06:04 PM

  1. Sometimes want to build archives from scratch (e.g. new architecture)
  2.  
  3. There are many build-dependencies loops.
  4.  
  5. Two kinds of build-dependencies:
  6.  - ?
  7.  - ?
  8.  
  9. lool has An Idea for this: stages for the builds, documented in the
  10. debian/control file.  Each stage can have different build-depends.
  11.  
  12. Subject to bitrot as build-dependencies change.
  13.  
  14. Steve keeps coughing and saying 'multiarch'
  15.  
  16. cross-build is always necessary to get the toolchain.
  17.  
  18. Need a tool to plan a build-campaign (other than lamont)
  19.  - debian and ubuntu have different tools for this
  20.  - can start with just documentation (?)
  21.  
  22. *could* extend to be able to build-depend on a package in a particular stage,
  23. but probably better to rename packages according to stage... or automagically
  24. mangle the version numbers by appending ~stage0 etc
  25.  
  26. Interface:
  27.  - stage field on source (list of stages the source can go through)
  28.    - dont let people name the stages
  29.  - stage field on binary
  30.  
  31. Do we need to work to prevent accidental installation of ~stageN packages
  32.  - or just rely on these packages not ending up in a published archive
  33.  
  34. In early bootstrap phases, building a source package will not necessarily build
  35. all of the binary packages that the final build will.  ? Not sure what this
  36. implies.  The existing partition of a source package into binary packages will
  37. not already be sufficient for this, do we split the packages in the main archive?
  38. Will this be too much overhead.  We already split packages for reasons that "don't
  39. make sense" like the main/universe.  How many packages would need to be split?
  40. Probably 30-40.
  41.  
  42. Some ideas trend in the direction of having stages for the entire archive.
  43.  
  44. Can't automate the bootstrap of toolchain for sure, automating the bootstrap of
  45. build-essential sure to be really hard.
  46.  
  47. A true, scorched earth, bootstrap has probably only happened 15 times in the
  48. last two decades -- how much effort is it sane to put into this?
  49.  
  50. How to actually specify the stages?
  51.  
  52. Adapting a package to build in stages will be quite a lot of work.
  53.  
  54. There is a relationship to cross-builds.
  55.  
  56. Can use/adapt debcheck to check our progress.
  57.  
  58. May need to extend launchpad's depwait stuff -- it's currently a bit simplistic
  59. and would need to be extended to be aware of stages.
  60.  
  61. How do we build build-essential?  Launchpad's build-dep graph stuff implicitly
  62. assumes it's there already!  Maybe just write a big script for this.
  63.  
  64. Is it going to be easier to just build build-essential twice than do a scorched
  65. earth rebuild?
  66.  
  67. Aren't aiming for full-archive scorched archives at first -- but first bit is
  68. obviously the hardest.
  69.  
  70. Three use cases/mode:
  71.  - really from scratch run binaries, not cross build
  72.  - cross build
  73.  - new abi
  74.  
  75. A prototype would be:
  76.  - select a set of packages we want to build (e.g. build-essential)
  77.  - make changes to:
  78.   - the source packages
  79.   - dpkg-dev
  80.   - the build scheduler
  81.     - this is wannabuild in debian
  82.     - "soyuz" in launchpad
  83.   - tools that resolve build dependencies:
  84.     - sbuild
  85.     - launchpad's 5.5 year old sbuild (or move launchpad to newer sbuild)
  86.  
  87. == ACTIONS ==
  88.  
  89.  * lool: spec this more concretely
  90.          take it to debian
  91.          prototype
  92.  
  93.   * dmart: ping steve mcintyre

Raw Paste

Login or Register to edit or fork this paste. It's free.