[ On Thursday, April 18, 2002 at 15:38:57 (-0500), Frederick Bruckman wrote: ]
> Subject: Re: post-installation and rc.d enhancements
>
> [And then you go on and on about a Rube Goldberg scheme to chain rc.d
> directories.]

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 are confusing the meaning of "chain" here -- that's only one minor
alternative in my proposal, and something I'd happily do without (as I
say I've never used it in the first place and I've only included it as
an option because others have not only suggested it but shown they've
used it successfully for their own needs).

> Your fears are unfounded. pkg_ and local_ scripts will look just like
> the base scripts, except their full-path "command" value will not be
> in the base system. They will be installed into "/etc/rc.d/". The
> rcvar is set in the script, and it's mostly supposed to match the
> filename. "rcorder" doesn't care about anything below the first block,
> which block is invisible to the shell, so the PROVIDE and REQUIRE tags
> may drop the pkg_ or local_ prefix to permit a script to settle into
> the sequence in the same place as its non-prefixed doppleganger.

rcorder might not care, but that's not what I'm worried about.

> No one's suggested protecting the user from starting both "pkg_named"
> and "named", which is what your proposal seems to address -- for one,

Actually what I'm suggesting is the exact opposite.

Otherwise there's no point to giving pkg rc.d scripts separate
namespaces for their filenames and rcvar names since there would be no
need to allow for multiple scripts or rcvars with the same "basic" name
as by design no pkgsrc thing would ever use a name already used by the
base system, and of course no pkgsrc thing would ever conflict
(simultaneously) with any other pkgsrc thing.

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've shown at least two ways that my proposal allows for direct
integration into the dependency order of all rc.d scripts, regardless of
their $PREFIX and regardless of whether those $PREFIX values span
multiple physical filesystems.

> > The use of
> > separate directories keeps rc.d scripts under my proposed scheme 100%
> > identical to their current form...
> 
> Wow, are you on the wrong page. This is "tech-userlevel", where we
> discuss changes to NetBSD that are visible to to end users. There's no
> problem with extending the current form of the scripts. Perhaps such
> caution was warranted in other forums (tech-pkg), but not here.

Either you don't seem to grasp what I'm trying to say, or I'm not saying
it right.

I'm talking about a relatively minor tweak to the NetBSD base system
level /etc/rc mechanism, as it exists in -current today, to better
address the very same concerns Luke's proposal is intended to address,
but to do it without requring script name and rcvar name munging.

What I am proposing keeps _all_ parts of third-party rc.d scripts
compatible with (and indeed identical to) their current form and allows
third-party developers to maintain one single script for NetBSD that'll
be identical regardless of whether it would be integrated directly into
the base system, or whether it's installed via pkg in some arbitrary
$LOCALBASE, or whether it's installed manually by the end user in
/usr/local or /opt, or whatever.

Indeed what I'm proposing requires no change to rcvar names or rc.d
script names, at any time, regardless of how they're installed, or
where, or by whom or what.

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