This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-551568536-1104770558=:20498
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-ID: <Pine.NEB.4.61.0501031142521.20498@server.duh.org>

On Mon, 3 Jan 2005, Robert Elz wrote:

>   | No, it's definitely an objective.
>
> No, what files get put where cannot really be an objective

That's not the statement to which you were replying.

  "the packaging system is who manages files and keeps track of them"

This is definitely an objective, a goal, a policy, whatever the Hell you
want to call it.  It does not specify where things go as it is.  It only
says that the packaging system, not the admin, should keep track of
installed files regardless of their filesystem location.

> if we had a pkg_enable command, that would (just from its name) be a part
> of "the packaging system" wouldn't it? Then if it did the file copying,
> rather than pkg_add (or make install) that would meet your requirement,
> wouldn't it?

Sure, but that sort of thing isn't implemented yet.  And now that we've gone
from objective back down into implementation details:  which is easier to
implement as a first step -- just installing the scripts in a default-off
state and standardized location, or adding a whole new tool with which no
one is familiar yet and rubs against the grain of established experience?

(See below for what I mean about "established experience".)

>   | Strike "if it installs it" and you've nailed it on the head.
>
> Huh?    Now you're saying that if the default for PKG_RC_SCRIPTS were
> changed the way you want it, and I were to set it to NO explicitly, so
> the rc.d file is explicitly not installed by the packaging system, then
> you still want the package system managing the installed rc.d file?
> (since you struck out "if it installs it").

My desired default would be for there not to be PKG_RCD_SCRIPTS variable.
Such a change would treat rc.d files no differently from all other
configuration and support files, all of which (including rc.d scripts) can
already be turned off today using PKG_CONFIG=NO.

>   | Geesh, all we're talking about is making rc.d scripts consistent with all
>   | other configuration files.  What's so hard to understand about that?
>
> What I'm concerned about, and the higher level objective I have is
> "avoid deliberately confusing naïve users".

With what sort of users do you interact?

I'm working with the assumption that most new NetBSD and/or pkgsrc users are
actually migrants/users from other Unix-like OS's.  This jives with what
I've seen of discussions on netbsd.org mail lists.  Given that:

> I still believe that you're imagining somewhere (perhaps sub-consciously)
> that the rc.d scripts will, when installed, go in LOCALBASE/etc (or
> PKG_SYSCONFBASE/rc.d or someplace like that).

Oh, it's not subconscious.  I've said it explicitly a few times.

Where I work, we have some pretty genius-level Linux and Solaris admins who
would all be caught off guard by rc.d-type scripts not appearing in a
standardized "etc"-rooted place, typically in etc/<something>.d.  They may
be great at Unix-like OS's, but they are themselves naïve about NetBSD and
pkgsrc.

I'd put money down that at least one of them would try running daemons in
/etc/rc.local using the manpage as an invocation reference, before
discovering that the third-party software startup scripts were present after
all, scuttled away in /usr/pkg/share/examples/rc.d.  After all, the config
files were installed, so why wasn't the rc.d script right there with them?

This is why I see the current state of affairs to be *more* confusing than
installing the rc.d scripts by default.  I'm trying to consider the audience
as somewhat Unix-like-OS knowledgeable, at least enough to know that startup
scripts live somewhere in <some_top_level_dir>/etc.  (/etc, /usr/local/etc,
/usr/pkg/etc.)

> They cannot (by default) go anywhere other than /etc/rc.d and meet the
> objective of avoiding confusion.

Oh, that's just FUD.  We have config files in LOCALBASE/etc rather than
/etc; there's no reason rc.d scripts can't live there by default.  That
pathname is still configurable if you want them elsewhere.

>   That's (at least currently, and perhaps forever, since there doesn't
> seem to be much to be gained by inventing another parallel directory for
> this purpose) the only place where the scripts are known to actually
> function - anywhere else, they're merely example files and have to be
> copied to work (or the system startup has to be changed to make them
> function).

Sure, or you have to do some sort of manipulation (which is required for all
non-NetBSD platforms anyway).

Note this:  I am **not** requesting that it be integrated by default into
the NetBSD-specific startup; that would indeed need to be the job of another
tool capable of knowing OS-specific differences.  I only want to see the
files be installed and tracked by pkg_* by default.  The easiest and most
predictable way to implement that is to follow the PKG_SYSCONFBASE-root
policy.

>   | On NetBSD, that depends on the desired integration level by the admin.  If /
>   | usr is not separate from / (and in many installations, it's not anymore),
>   | adding to rc_rcorder_flags can integrate PKG_SYSCONFBASE/rc.d without
>   | intermixing base system and pkgsrc scripts.
>
> "Adding to rc_rcorder_flags" is not for naïve users

Nor is copying files into place, but:

> working "in many installations" isn't good enough in any case, all this
> stuff needs to work predictably in all of them.

And we go and add unpredictability by not installing the scripts to any
active location by default.  This helps things... how?

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>
--0-551568536-1104770558=:20498--