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>