On Aug 4,  6:53pm, Frank van der Linden wrote:
} 
} Ok, a few things:
} 
} 	* As I've said before, please don't start about the "BSD way"

     Why not?  We are running NetBSD, not NetSYSV.  And, one of the
major factors in the decision for running NetBSD for many of us, is
because it is BSD (or a very close derivative of it).

} 	  of doing things. You are free to run your own setup,
} 	  use another OS, or go find yourself a VAX to run 4.2BSD on.

     I don't consider BSD to be a particular release, but rather a
philosophy.  I also don't consider 4.2BSD on a VAX 11/780 to be
particularly practical or useful today.

} developer, and no new rc system. You can't please everyone, you
} have to move forward.

     Just on general principles, in answer to this statement, I must
say "Why?"  I'm not a nochangenik, but at the same time, I don't
believe in change, just for the sake of change.  There must be clear
advantages to the change before it goes in, and it mustn't break or
cause other problems.  Purely experimental stuff should be done on the
developers own machine, or if it is a really big project, then on a
branch.

} I'd hoped that, once people started using it, more constructive and
} practical suggestions would come up, but unfortunately there is
} already a tendency towards loudness rather than content.

     Although I may make suggestions, at this point I'm going to stick
to generalities.  I'll wait until I see the final product before I
"scream bloody murder".

} What are the open issues? The main one is that there should be an
} easy, well-documented way to drop in scripts for 3rd-party packages.
} Documentation is lacking, yes, but Luke said he will write it.
} Dropping in scripts currently does mean editing rc.conf, which
} isn't the easiest way. So one can either split up the config
} files or write an automated tool that deals with rc.conf. Either

     Personally, I would prefer to see a single rc.conf with an
automated tool that deals with it (probably as some kind of library
routine).  As shipped, rc.conf easily lends itself to being modified by
automated tools.  Perhaps a compromise for those that prefer it not be
modified by automated tools, those people could add a line like "#@ NO
AUTOMATION" to the top of the file, which would tell the automated
tools to keep its grubby hands off of it.  Presumably in this case, a
warning message would be spit out advising the sysadmin that a change
is necessary.  The sysadmin could then decide what to do.

} one would work for me. Then there's pkg and local scripts, but
} that just seems a matter of picking an option.

    I would suggest that pkg scripts get lumped in with the system
stuff.  There should be an easy way of "activating" a pkg which is NFS
mounted.  As for local scripts, well they are local scripts and the
sysadmin can do anything they want.

}-- End of excerpt from Frank van der Linden