[ On Friday, April 19, 2002 at 13:24:12 (+1000), Luke Mewburn wrote: ]
> Subject: Re: post-installation and rc.d enhancements
>
> 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.

My proposal has nothing specific to do with handling LOCALBASE=/usr --
that's merely an alternative that it makes no more difficult to handle
(as opposed to your proposal which, on first glance, i.e. without seeing
a full implementation, seems to make impossible, at least not without
destroying some of the transparency such as setting is designed to
achieve).

My proposal does however try to deal with the potential for integrating
a third-party maintained rc.d script into the base system and not
requiring any changes at any level.


> 	+ 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.

I do agree.  I've only put emphasis on the way my proposal allows for
this ability because that's the only reason I could imagine for your
proposal needing to create a separate namespace for package rc.d scripts
and rcvar names.  If you really don't think it's worth the effort to
support multiple instances of what are effectively the same package then
you don't need such namespace separation at all.

(What would be nice though is a way to detect, perhaps not at runtime,
but maybe through some separate analysis tool, conflicts between base
system tools and the various replacements that might be found in pkgsrc
or even in manually installed things.  For example named, sshd, etc. all
come in the base system, but variants of each can be installed too.  If
the base sshd is "sshd", and the pkgsrc sshd'd are called "openssh",
"ssh2", etc., then they can all be installed at the same time and they
can all have unique rc.d script names and  rcvar names, but they can't
all run at the same time so only one of them can be set to YES.  Maybe
if one of the "KEYWORD" tags is identical in each?)


> 	+ the majority of our users just install packages with default
> 	  settings (into /usr/pkg).

In that case it is possible to completely avoid name clashes in the
first place!  I.e. simply do _not_ create any packages with conflicing
rc.d script names and/or rcvar names (either between packages or with
any base system software)!  (or at least not allow them to be installed
simultaneously by registering conflicts)

>            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).

That's easily addressed within my proposal -- and would presumably be
the default for NetBSD.

>            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, ...

I know several people who really don't even like having to type the
/etc/rc.d part in the first place and I know one person who doesn't like
it enough that he's written a script that can be invoked as any one of
the action names with an rc.d script name as its command-line operand,
and which then finds the right rc.d script and runs it using the
appropriate action name as the script's command-line operand:

	stop named
	start named
	reload named
	... etc.

I'm very tempted to adopt his script even for machines where I have only
one rc.d location (i.e. all scripts in /etc/rc.d).


> Having a "pkg_" prefix or "_pkg" suffix on filenames/provisions/variables
> is arguably not the cleanest approach

You can say that again!  ;-)

Unfortunately it seems it will make it quite a bit harder to also allow
clueful people to do more complex things in less intrusive ways --
i.e. without having to maintain extensive and invasive local source
changes.

I'm trying to propose knobs that won't get in the way of the default way
of doing things, and which provide sane ways to get much, if not all, of
the functionality various other people have asked for in one way or
another before, including the ability to use separate namespaces if and
where they're necessary.

I can do the things I want to do in several different ways right now,
with today's rc.d implementation, without making any massive hacks to
the base system -- I just tweak some settings, create the odd symlink,
and all is happy.  It's really not necessary to change anything to get
the kind of integration most people desire.  Name frobbing is definitely
not necessary at all.

Your proposal involves invasively changing a great deal of stuff that
I'd really want to undo to keep things clean and consistent (and able to
be invisibly/transparently integrated), but which would cause me great
pains to undo and would involve ongoing headaches to fix and re-fix
every time I merge with the "official" sources again.

Using directories to avoid name clashes is the de facto unix standard
way....  Don't fool yourself that putting prefix or suffix strings on
the file and variable names is any less jarring to a user.

More fundamentally though why should the average user be required to
know that 'named' is installed as a package on a given system?  My
scheme allows for complete merging without any name frobbing, and I
would expect that to be the default way NetBSD ships and that most
people would use it.  My scheme also happens to also allow for handling
multiple packages using conflicting names by separating them into
mutliple hierarchies.

>  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.

I agree with keeping configuration and scripts in one location as well,
which is why my proposal includes that possiblity as a first-rate
feature (with several alternative implementations), and why it does so
without requiring packages to be installed entirely on the root
filesystem.

Perhaps we need to step back and look again objectively at the
requirements for the default system configuration; then prioritise the
special requirements others have put forth (including my own! ;-); and
finally see how these can all be met so that only the least important
requirements require any invasive changes.

Obviously I feel that my proposal already does this in the best possible
way.  However without yet having seen any direct critique of it I'm
unsure what things I may have miscalculated.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>