On Tue, 12 Nov 1996, Mark Brinicombe wrote:

> Q: Which are the main problem areas. The install script used during
> partitioning etc., the inst program to manage set installation or the
> configuration after installation ?

Inst needs the bug fixed which prevents it from displaying the sets 
available in the distribution directory. Then it's OK again, it may be 
slow but that's not important.
If it doesn't execute the set scripts any more, this has to be clearly 
stated.

The whole NetBSD installation routine (to get the system partitioned and 
the basic stuff installed) is embarassingly bad IMHO. It's pretty 
uncomfortable but I don't know if that's causing problems.
It only caused problems for me when it was broken (gunzip not working and 
so on).

> I am working on a new installer  (design stage at the moment, no coding yet)
> that will replace the current inst script etc.
> This installer will provide a basic functionality similar to the exising set
> installer but will be far more intelligent/faster.
> It will managed installation histories, full conflict detection / resolution
> all other set inter dependancies. Check for overwriting of modified files will
> backup critical files, will merge user changes to config files between versions
> (i.e. you will be able to install a new version of the etc set over the
> existing one and all you local changes to rc.local / rc etc. will be merged
> into the new version.)
> Other facilities will include functions to allow you to find out which sets
> have been upgraded since you installed and whether upgrades are necessary,
> recommended, optional etc.

That sounds great!
The set files have to be maintained carefully though for this to work 
properly ie. the program can't inform you of new sets if the set file 
wasn't updated.

> The installer will support installing from all block devices, nfs, ftp etc.
> will support multiple types of filesystem and their corresponding filename
> mangling etc.

This would also be great.

> The aim is to have an installer that can be driven from the command line as a
> first step.
> 
> Then either text based, X based, Tk based frontend can be built around it.

That's the most sensible approach IMHO because, as I said before, X may 
not be working for whatever reason and it's inefficient to write two 
complete installers, one X based and one who isn't.

> Regarding the installation script used for paritioning ...
> Ok I can understand people not liking the geometry stuff. This geometer stuff
> could be replaced without too much work. ioctls exist to obtain the geometry
> and the start of the RiscBSD part can be found in the same way that the kernel
> does when obtaining the disklabel. Then all that is needed is a simple program
> to ease the choosing of the partitions. Somebody else want to do this or do I
> move this up my priority list ?

It should be possible to find somebody else who can do this. One just 
needs Unix programming knowledge for that. 
You should stick to things only you can do IMHO, ie. kernel hacking.
There are bugs which should really be fixed and the kernel is not perfect 
yet. I think you will never run out of work on the kernel.
OK if you prefer to work on other things as well because kernel 
programming only is too boring this is your (understandable) decision, 
but the project would benefit best from you working on the kernel IMHO.

> All the post install config stuff has been done as scripts and I have tried to
> keep them as simple as possible.
> Readme files / man pages may be useful for these scripts (any takers ?)

They're pretty self-explanatory, but you have probably seen the stuff 
about Ethernet which Jan-Uwe wrote and the SLIP stuff I did. (Btw, Jasper 
sent me good comments about it and I hope to get an improved version 
which is good enough to be put on the ftp site out before the end of the 
week.)
We could do the same for other subjects. I'll have a look.
Now it gets more and more urgent to decide whether to put this in a 
common framework (called the RiscBSD Handbook or whatever) and what parts 
can be used from other sources (FreeBSD, Linux).

> Feel free to modify/fix or write new config scripts and I will happily add them
> to the config set.
> For example the user config script does not allow new groups to be defined yet.
> Also it does not provide the option for adding users to extra groups in
> /etc/group. These functions need to be added to the script and sooner or later
> someone will have to do it ...

FreeBSD has an adduser script. Why not use this and its documentation.
Don't remember if it has big shortcomings.

> One of the problems perhaps is that I don't apprieciate that for a
> inexperienced unix user it may seem very complex. Having installed RiscBSD so
> many times I don't even bother to read the text in the install script etc, I
> know what the prompts are ;-)

The same applies to everybody who has become familiar which all the 
odds and edges of the systems.

> I think a key  to this is the install guide. If the install guide clarified
> things and explained things better a lot of the problems would vanish.

I really hope Kjetil will bring this out soon, no matter if it's finished 
or not. I mailed him when he said people could get it by EMail for 
reviewing, but he obviously didn't get it out before he went to England. :-(

> I'm in a no win situation ;-( what ever part of the system I am working on
> there is always something else I should be doing ;-)

But there are things which can be done by others and things which can't. 
You should stick to the latter whenever possible. But there's always the 
problem that workaholics attract work. ;-)
 
> For example all my spare time that I will have today has already gone just
> reading and replying to RiscBSD email.

But don't come to think this is wasted time please. We need the 
discussion and coordination. In the end, this will help to distribute 
work better.
 
> What is really needed is a month or so of solid RiscBSD work. This I think
> would solve a lot of the problems with the current release etc. however this is
> not possible on a project like RiscBSD.

How much could it cost to hire you? Maybe we can raise enough money to 
make you a full-time NetBSD programmer. ;-)))

> Users are now getting more involved with the development of RiscBSD (no 
> budding kernel hacker yet ?) and I hope some of the fruits of the 

If you can tell me how to become one... ;-) How did you (and the 
others from the kernel team) learn so much about BSD that you were able to 
port the system? This seems to be almost impossible for me as it's so 
complex and there is no documentation which covers all of NetBSD.

> RiscBSD Documentation Project will start to appear soon so hope fully 
> things will get better in the next few months.

I'm sure it will.
It has improved a lot in the last few months (despite some new problems 
showing up), let's not forget that.

Markus