Hi, unfortunately, the recent sysinst rewrite ceased. But there are features current sysinst is missing, and which are complicated to implement (that is, gpt, raid, cgd modifying). The questions is: What to do about them? I've been thinking about this quite a long time... Ok, first have a look at the other BSD installers: * FreeBSD - they just created their new bsdinstall(8), which is mostly a shell script calling other shell scripts, directly using dialog inside these scripts. While easy to extend, you cannot add other interfaces easily. I read they wanted to make an easy interface to pc-install (or whatever it is called), the graphical installer from PC-BSD, but I didn't look close enough at it to really sort out where. * OpenBSD - has a single shell script. Perhaps I just mis-read that, can somebody object this? * DragonFlyBSD - has bsdinstaller.org, which comes close to mbalmer's initial approach. It's a flexible combination of Lua and C with several interfaces (gtk, Qt, cgi, ncurses). They already wrote code to make it run on NetBSD, as far as I see. I dislike them all. The FreeBSD installer uses directly dialog, which makes it useless for automation. The OpenBSD approach anyway. The DragonFly approach is very nice, I'm just a bit uncomfortable about its complexity and its "separateness" from the userland. The current sysinst has several disadvantages: * though sysinst is very nice code and easy to modify, it's still C, which makes it complicated, especially treating menus. * there's currently only one interface - though it should be easily possible to extend that to further interfaces, you had to modify msgc(1) and menuc(1). * parsing output from shell tools is difficult. Talking about disklabeling and mbr'in, it's done in sysinst again. So I'd like to propose writing a new installer. Not completely from scratch, there's too much information in the old installer, but write a new backend and provide the md parts of current sysinst as modules (though that is much work to rewrite). The other way would be to maintain compatibility and use another installer. OpenBSD's install script is not worth maintaining compatibility (as there's no interface). FreeBSD's bsdinstall(8) is imho too unflexible wrt different interfaces. bsdinstaller.org seems just right, but I didn't look that closely at it. It seemed very complex, more than what I would think about being needed, but perhaps there's somebody here who knows more about it? An installer is not more than a combination of tools that are already present in userland (and some more logic and stuff for special platforms). And currently, there was also the discussion of including sysinst to userland... The only really tricky part is about disk setup. Labeling, mbr'ing, raid'ing disks is complicated to do, you want to have a nicer interface for that for beginners. So, why not combine this? E.g. both fdisk and disklabel support just showing the changes, and doing that via shell arguments (I'm talking about `-s' flag). Writing a disk utility that incorporates fdisk(8), disklabel(8) and gpt(8) is imho an important part of this, though not directly related to the installer. The installer itself should need as less logic as possible, being only a middleware between the frontend, i.e. either a cgi, curses, automatic, graphical or scrolling interface, and the backend, consisting of very short wrappers for these tools. Then, rewriting sysinst would also contain writing wrappers, and perhaps even modifying current userland tools to better fit automation. You could much better reach a uniform handling of the OS if you had this. If you could as well control all the userland administration utilities (being a bit megalomaniac) with any interface you like, because they were made to fit automation, and thus interface flexibility, would be the greater goal. I know all the existing approaches for these system management tools like yast and whatever they're called are terrible, but this is different. It's just about a wrapper for existing tools. To be more precise (let's take e.g. sh): There is a list of definitions of options, their names, and their descriptions. You have a function called `getconf`, which has as a single argument the name of the option to ask for, then shows its text and you enter the argument. This is a very simplistic view, but works for most of the things being asked by the installer. You could do that with several interfaces, even autoconfiguring (which is an important goal for me). I already have such a script for me, it's about 1000 lines of sh code all-inclusive. Coming to lists, there could also be an interface that e.g. gives out all the text, and provides a method to address single lines. Then, there are hooks before and after every action that is being taken, executing md or user-delivered code. Though this project sounds large, I don't think it is. Wrapping tools is easy. Ripping out the md code from sysinst might be more work, but the way it is structured and written there shouldn't be much to do. I just want to clarify everything, especially the protocol once you agree about the way before starting with this one, and perhaps finding others to work on it, too. I also think taking a deep look at bsdinstaller should be done before any wheel is invented a second time in another language. Perhaps even cooperating with bsdinstall could be an option. At least they already did the wrapping, just that they implemented the interface right in the installer. Megalomaniac regards, Julian
Attachment:
signature.asc
Description: PGP signature