Subject: Re: post-installation and rc.d enhancements
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Luke Mewburn <>
List: tech-userlevel
Date: 04/19/2002 13:24:12
On Thu, Apr 18, 2002 at 05:52:24PM -0400, Greg A. Woods wrote:
  | I think you'd better ask Luke to translate what I've been saying into
  | your language.  From the impression I got from his initial response he
  | at least understands what I'm trying to say.

You have the wrong impression.  I did not specifically attempt to
address any issue that you raised.  To be honest, I often find it
difficult to wade through a long winded side-discussion between two
or three people arguing over minor points... (I'm contributing to this
with this post :)

  | My goal is in fact to allow simultaneous installation of the very same
  | package in any number of hierarchies (including the base system), and to
  | allow for "simultaneous" execution of any rc.d scripts, each with the
  | ability to experience different configuration settings (i.e. have unique
  | ${name}_flags values even though $name is identical in every case).

I would argue that:

	+ a small number of our users would be setting LOCALBASE=/usr.
	  Said users should be clueful enough to solve any problems that
	  results in.

	+ a small number of our users would have multiple package
	  heirarchies installed.  Said users should be clueful enough
	  to solve any problems that results in.

	+ the majority of our users just install packages with default
	  settings (into /usr/pkg).  I assume that they would prefer to
	  have a consistent location for configuration (/etc/rc.conf,
	  /etc/rc.conf.d/foo), and a consistent location for rc.d
	  scripts for manual startup (/etc/rc.d).  As an end user, it
	  would annoy me to no end to remember to type /etc/rc.d/foo
	  for "base NetBSD" scripts, /etc/rc.pkg.d/bar for package items,
	  /usr/local/etc/rc.d/baz for my stuff, ...

Having a "pkg_" prefix or "_pkg" suffix on filenames/provisions/variables
is arguably not the cleanest approach, but it does keep the
configuration and manual control of the rc.d system scripts in one
location, and that is a benefit that a few people requested for and I
agree with.

Too often people request/exclaim/shout/browbeat for functionality
that will really only be used by a minority of users (often the
"hypothetical user"), which unnecessarily increases the complexity
of our system.

For those people who want to do Tricky Stuff (tm); they have the
source, they can edit their local systems.  There is no need to
force their Superior Design Skills down everyone else's throats.