Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 May 2004 16:36:53 -0700
From:      David Johnson <david@usermode.org>
To:        freebsd-libh@freebsd.org
Subject:   libh/sysinstall ideas
Message-ID:  <200405231636.53068.david@usermode.org>
In-Reply-To: <Pine.NEB.3.96L.1040523121543.95236B-100000@fledge.watson.org>
References:  <Pine.NEB.3.96L.1040523121543.95236B-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
I've been thinking about a libh/sysinstall replacement for quite some 
time now. I've even committed to coding something up, but various 
events have conspired against me. I probably won't get a chance to 
actually code anything for three months. I'm more than willing to help 
with someone else's ideas instead, though. But in the meantime I'm 
going to through out some ideas.

The project needs to be split up into managable sized pieces. Each piece 
should be a useful component in and of itself. There are several 
benefits to this. First it adheres better to the UNIX philosophy than 
libh did. Second and most important, it allows greater participation. 
It would provide some working code sooner, and allow interested 
individuals the opportunity to pick up some minor unfinished pieces to 
work on.

I would divide the domain into three separate projects: installer, 
configurator and package manager. The installer is only concerned with 
bootstrapping, partitioning, labelling, and getting the base system 
installed onto the drives. It might or might not use the package 
manager. The package manager should need no explaining. The 
configurator is what we think of sysinstall, without the initial 
installation functionality. The configurator would be modular. Each 
"page" in the interface would be a different module, independent of the 
other modules.

All of these parts should have a their interfaces strongly decoupled 
from their functionality.  The functionality itself would be provided 
by shared libraries. Then there would be separate graphical (Qt) and 
text mode (curses) interfaces linking to them. Perhaps even a separate 
CLI interface useful for scripting. This would avoid the hassle of 
trying to create a unified gui/tui interface.

A secondary idea for the interfaces is to create a dialog/libdialog 
replacement that can handle either GUI or text dialogs. That way the 
entire interface can be scripted, regardless of interface mode. 
Slackware managed to create its entire installer with bourne shell and 
dialog. An enhanced dialog combined with ruby could make a very 
flexible installer!

I came up with this very broad high level architecture because I wanted 
to contribute something to FreeBSD, but a complete sysinstall 
replacement was simply too much for one person. This way I can work on 
just one piece.

-- 
David Johnson
___________________
http://www.usermode.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200405231636.53068.david>