SEUL: seul-dev-install

["Luka@pop3.aracnet.com (Peter)" <luka@mit.edu>]

seul installer development.

this group writes software to get the user from *wherever* to a running
seul system, with minimal effort on the part of the user.  this can be
installing a system from scratch, or installing over or next to an existing
os.  and if the user is trying to preserve data (as indicated by answering
a question like "do you want to keep another os which is currently installed?")
then the installer should be extra careful about not destroying data that may
be related to that os.

the installer should also be excessively verbose about _what to do_, if an
error occurs.  diagnostic info may be useful if you know what it means, but
the seul target user may not know a thing about linux or os jargon, so what
they need is instructions on what to _do_, to make things work, or pointers to
more info if necessary (and don't say look on the net, if they don't have a
net connection up yet!).  above all, make an effort to _never_ leave the user
stranded, with no instructions on the screen.


things that need to be implemented:

 1. 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 things:
      o user-friendly
      o 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.

 2. 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
    to work.

 3. 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!

 4. 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 is done.

 5. 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 down
to 4 and 5, where things need to be done such that they fit together
with the rest of seul.


-luka
----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------