| 1 |
- micodebconf [Glenn McGrath <bug1@netconnect.com.au>,
|
| 2 |
"Bernhard R. Link"
|
| 3 |
<brl@pcpool08.mathematik.uni-freiburg.de>,
|
| 4 |
Randolph Chung <tausq@debian.org>]
|
| 5 |
- microdpkg [Randolph Chung <tausq@debian.org>]
|
| 6 |
- main menu [Joey Hess <joeyh@debian.org>]
|
| 7 |
- more detailed design docs that other people besides Joey Hess can
|
| 8 |
understand [Joey Hess <joeyh@debian.org and debian-boot]
|
| 9 |
- The main menu design has some issues. If a step is failing
|
| 10 |
because some step above it did something wrong, but thought it
|
| 11 |
succeeded (a disk was partitioned, but very badly, and installing
|
| 12 |
the base system to it fails), there is no way to force the user
|
| 13 |
to back up. This seems to preclude linear install mode. I posted
|
| 14 |
a longer example to -boot. Three possible fixes:
|
| 15 |
- Detect loops, and have code to figure out what went wrong
|
| 16 |
and back up to the appropriate step that can fix it
|
| 17 |
- Detect loops, and back up to the beginning of the menu
|
| 18 |
- Detect whenever any menu item fails, and leave linear
|
| 19 |
mode. (BEST)
|
| 20 |
- Items on the main menu should be able to specify that they depend
|
| 21 |
on some package being configured. If it is not, they are not the
|
| 22 |
default. There are several ways to do this..
|
| 23 |
- Need to define module subsystems for network/hardware support,
|
| 24 |
network configuration, target media support, etc.
|
| 25 |
- Cobble together a demonstration system that can install onto some very
|
| 26 |
limited set of machines, in some very limited fashion. Here are the
|
| 27 |
things we would need for such a system:
|
| 28 |
- mini-debconf
|
| 29 |
- one debconf ui
|
| 30 |
- one retreiver and whatever it depends on
|
| 31 |
- main menu
|
| 32 |
- disk partitioner
|
| 33 |
- disk formatter
|
| 34 |
- base system extractor
|
| 35 |
- lilo setup
|
| 36 |
- reboot
|
Parent Directory
| 
Revision Log