Clarify design goals

[zeha]

Need to clarify what grml-debootstrap should be, and which usecases it should support.

From our in-person discussion, I think we want:

• clear commitment to being an installer for pure Debian systems
• installed system should mostly work like Debian
• should provide clear recipes
  • VM image (like Debian cloud image)
  • inside VM install
  • baremetal server
  • "Debian Developer laptop/desktop" (excluding any graphical things, to be left to the user)
• partitioning should be part of the recipe
• bootloader should be automatic and have an opinionated choice
• amd64 VM images should support EFI + bios boot
• archs: amd64, arm64
• target suites: unstable, testing, stable, oldstable, oldoldstable (cf drop legacy support: stop supporting oldstable and older #282)
• all features should be CI tested
• dialog frontend and command line
• "featureitis" should go away
• full encapsulation of called tools
• customize hook for the in-chroot phase

[zeha]

Features we think which can or should go away:

• --iso (can) - uninteresting to us to take debian packages from an iso
• DEBOOTSTRAP=... (should)
• DEBOOTSTRAP_OPTS=... (should)
• ?

[adrelanos]

As mentioned in #309 (comment), for our Debian derivative distributions we need variable DEBOOTSTRAP and/or DEBOOTSTRAP_OPTS (as proper bash array).

[zeha]

We also know that we need support for per-release package lists, as the available packages and useful defaults change per Debian release.