- An fdisk/fips that rocks! (read "disk setup utility")
Current fdisk programs are not user-friendly, are not robust enough to
deal with weird stuff (such as the latest microsoft product) on the disk.
fips should also be integrated with this setup utility. Important
- Robust and relatively safe
Warn the user more if something is likely to fail, rather than just
offering a disclaimer every time a write is requested. And remember to
keep the front/back end separated, so that the back-end can be integrated
with the rest of an installer easily.
- Device detection code
Gather and write code necessary for making all common setups be
detectable reliably. Document which parts are reliable and which aren't:
this info will go into hardware support publications.
If kernel hacks are necessary for this stuff to work, make sure they are
really necessary, and if so try to get the linux kernel team to do stuff.
It would be poor if we have to ship with a seul-hacked kernel for things
- The rest of the installer.
We should almost certainly start by grabbing the best publicly
available (ie gpl'd) installer, enhancing it to be friendlier, fixing the
"why can't someone just go in and fix that?" bugs, adding the increased
device-detection support, and integrating everything to run smoothly from
start to finish.
And add seul-specific stuff (4).
But try to keep the general installer fixes separate from the
seul-specific changes, at least when starting out: this way, we could even
let the original distributor take the improved installer and use it, and
perhaps they'll end up distributing an alternate seul-enhanced version for
us as well!
- Seul-extensions in the installer.
The concept here is that the installer will support a higher-level
packaging scheme than what is currently in use. The installer should
provide a framework for selecting things like "typical", "full",
"minimum", and "custom", installs, and each should be in the context of a
particular type of user.
Redhat already implements some stuff to support configuring sets of
packages to be used in an installation. This needs to be enhanced,
though, to allow easy configuration of user/install-style, and to pass
through info on package-sets to the seul database developed by the admin
group. Ignore that last part for now, but be ready for it when the spec
- Gui/help system hooks.
SEUL will be developing a uniform help system and gui. This is not a
major concern right now for the installer, since it can be pretty
independent of everything else. But if possible, the installer code
should make a clear distinction between the front and back ends, so the
gui can be replaced someday without having to understand how the installer
works internally. Also, help routines should be abstracted into a set of
routines that are grouped together and can later be easily identified.
The installer work is mostly independent of the other groups.
Implementation in the order above means a lot can be done before you get
to 4 and 5, where things need to be done such that they fit together
with the rest of SEUL.