tech-install archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: reworking sysinst



Hi,

> sysinst: Addition of a Lua interpreter, initialize it, provide bindings
> to sysinst functions, call-back into Lua code
> ...
> Contributions to this project are very welcome!
though I won't be able to really contribute immediately, these are my
suggestions for the design:

 * Don't modify sysinst, but rather write a new backend.
   sysinst is for installation, but if you want to have it for configuration,
   too, you want to break the sequentiality of sysinst.
   Current sysinst can still be used in parts of that, especially for the
   platform-specific part and (in the beginning) for partition manipulation.
   Having sysinst as a generic configuration tool should be considered
   forefront.

 * The menuc(1) and msgc(1) frontends have a very nice principle, but I think
   you should modify it. On the one hand, having it really uniform would be
   good. No msg_display_add, then messages inside the menus, then
   msg_display, etc.
   Only msg_display and msg_display_add, and menus for different types. No
   code inside menu actions, only set variables.
   This simplifies adding other interfaces (e.g. a web interface, a scrolling
   interface [nice for slow terminals], a graphical interface, a
   not-interface of preconfigured values).
   You should think about the menus and options, etc. you have always in the
   manner of automating sysinst and clarifying the options as much as possible

 * Disk editing could undergo great improvement when doing sysinst.
   Currently, there are three tools which require very different handling
   each (disklabel(8), gpt(8), fdisk(8)), plus installboot(8). I think having
   *one* tool with the same capability as sysinst, but also different
   interfaces (or one old interface and an interface for sysinst), would be
   nice. All in all, share code between disk labeling tools and sysinst.

 * Have a system where every functionality of sysinst is a plugin. Then, have
   a priority or dependency order with some keywords (as 'beforedisk', 
   'beforenet', 'beforeinst', 'afterinst', 'finish', etc.). You have to save 
   state of plugins anyway to save e.g. the network configuration.
   So, perhaps also for a plugin several functions/methods to be called, one
   for configuration, one for saving configuration, etc.

My goal with sysinst is to have a flexible tool so you can configure it to
install NetBSD fully automatically, or preconfigure installation or live media
so that you only have to run one tool and most of the preconfigured things
will be done automatically (nice for e.g. rescue disks).
Plus, the possibility of having no curses, but a simple scrolling interface is
*very* nice with slow terminals (9.6k and curses is terrible), as would be an
http interface (as bsdinstaller has). This is not much work, you just have to
think about the order in which the questions are being asked, etc.


These issues are known anyway, I just want to add something to the discussion
and write them down.


Regards, Julian

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index