Date:        Mon, 3 Jan 2005 12:40:02 -0500 (EST)
    From:        Todd Vierling <tv@duh.org>
    Message-ID:  <Pine.NEB.4.61.0501031142320.20498@server.duh.org>

  | 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 might be a policy, but we have (should have) policies only when they'r=
e
to meet some objective.

The objective (maybe, I don't want to put words into your keyboard) that
you're dancing around here might be "Make things simpler for the admin"
or "less work required of the admin" or something like that.

Everything else is just a technique that you're hoping will achieve
that goal.   Until we understand the actual goal though, we cannot
determine if your proposed technique is the best way or not - we can't
even be sure that the goal is worthy of consideration.

  | Sure, but that sort of thing isn't implemented yet.

Of course not.   But one of the NetBSD principles seems to be do
do things the right way, not the wrong way just because it is expedient
right now.   Of course, before we can do that, we have to know what is
the right way, and that includes exploring the possibilities.


  | With what sort of users do you interact?

In this area, the ones who ask questions on the lists.   "The rc.d script=

is in /usr/pkg/etc/rc.d but it doesn't seem to be being run, what did I
do wrong?"

  | I'm working with the assumption that most new NetBSD and/or pkgsrc us=
ers are
  | actually migrants/users from other Unix-like OS's.

Most of the ones I deal with personally are actually refugees from BillOS=
=2E
But most of those never get as advanced as actually installing a package
that needs an rc.d script.

  | Where I work, we have some pretty genius-level Linux and Solaris admi=
ns 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.

I suspect they'd be more caught off guard by having them appear in a plac=
e
where they're ignored at boot, regardless of the name of the directory.
They're more likely to start daemons from rc.local if they discover that
a reboot doesn't start them automatically, than by noticing the script in=

an unusual place (or more likely, not noticing it at all - whether it
has an etc name or not).

  | > 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 th=
an
  | /etc; there's no reason rc.d scripts can't live there by default.

No, they're not the same at all.   Other config files go (have to go)
wherever the utility that's using them expects to find the things.
For pkgsrc utilities that's generally (by virtue of pkgsrc patches if
necessary) in PKG_SYSCONFDIR or LOCALBASE/etc or whatever.   rc scripts
are data for the rc subsystem, which (on NetBSD) expects to find its data=

in /etc/rc.d (by default).  Thus, to work, the rc.d scripts have to go th=
ere.

  | That pathname is still configurable if you want them elsewhere.

Yes, exactly - that's fine - if *you* want them other than in /etc/rc.d
you can put them there - but for your na=EFve admins, or mine, who just
expect an installed rc.d script to get run, without having to invoke any
special magic to make that happen, they need to go in /etc/rc.d

Or look at it another way - your experienced on other systems admin
discovers that the daemon doesn't start at reboot.  He/she knows that
rc.d (init.d, ..) type scripts usually make that happen, so looks at the
package to see if there is one.   (May take a bit of hunting, but eventua=
lly
pkg_info and its -f option will be found).   In the current setup, the
admin will see a file installed in an "examples" directory.   Just about
anyone is going to be able to reach the conclusion "here is an example of=

an rc.d script that I can use for this package, now I just need to look
at it, perhaps change it, and then install it."   That might be a bunch o=
f
unnecessary work, but it is all simple, and not at all perplexing.

On the the other hand, if the admin finds what has been installed, sees
an rc.d script, and sees that it has been installed in an etc/rc.d direct=
ory,
but the thing is still not being used, what's to be done?

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

Manipulation for non-NetBSD platforms can be made part of their pkgsrc
bootstrap sequence, that shouldn't be an issue.   There's no bootstrap
sequence for pkgsrc on NetBSD, it's there already.

It is also not just "some sort of manipulation" - to be fully general,
the directory has to be on the root filesystem, that is, we have to be
able to assume it is there - otherwise a bunch of things just aren't
possible (for people who install packages on other filesystems, some of
that won't be possible anyway - but for people where the packages are
on the root, then we cannot have the rc.d system stopping them working
to the fullest extent).

Note that this next bit is not na=EFve user stuff - this is making sure
that what you're proposing isn't breaking the flexibility for experts.

With rc.d scripts in /etc/rc.d I can make /usr and /usr/pkg be
"critical filesystems", so they're mounted early, then arrange to
have rc.d/tspc run very early in the sequence, and then use the
IPv6 (tunnel) it makes to NFS mount other filesystems as part of the
normal boot sequence.   That works because the script order (including
pkgsrc supplied scripts) can be processed at startup.   But if you're
going to make pkgsrc rc.d scripts on non-root filesystems work in the
general case, then you have to postpone including them until after all
the filesystems are mounted (as you can never really be sure which one
they're on), which means that you can't use any of the pkgsrc stuff as
an assist in actually doing the mounting (including all network setup).

Of course, you could leave it to each individual admin to fiddle
the rc system config in a way that uniquely meets the needs of their
particular system, but that wouldn't be meeting what I've assumed is
your real goal, of "making things easy for the admin".    It certainly
isn't something that I'd be expecting even a NetBSD admin of average
experience to easily get right.

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

Hmm - now I am confused.

  | I only want to see the files be installed and tracked by pkg_* by def=
ault.

But that is done now.

It seems as if the only thing you're arguing about is the name of the
directory they go in, which is the last thing I was expecting.

Until a week or two ago we had packages being installed in .../etc/rc.d
and that simply wasn't working.   That is, it was causing confusion.
That's precisely why it was changed - that directory wasn't a functional
rc.d directory in the same sense as /etc/rc.d is, it was really no more
than a directory of example scripts that could be installed (or which cou=
ld
be used in place by suitable magic playing with the rc system setup).

All that remains true today - the only difference is that the name of the=

directory more clearly indicates its status as a directory of example
scripts.   Nothing else changed.

Now I can certainly understand people wanting the scripts to be
installed in the "proper" place by default - that seems to be what
Dieter wants (not enabled, just installed) - but I really cannot see
any plausible justification for asking for them to be deliberately instal=
led
in a non-working place with a name that looks like it should be somewhere=

that just works - that's just deliberately misleading.   The only
thing it has going for it is maintaining the status quo from last month
(and before), and that's not much of an argument for retaining a bug.

  | > "Adding to rc_rcorder_flags" is not for na=EFve users
  | Nor is copying files into place, but:

Even the most na=EFve user can handle copying a file...   Knowing which
file and where to copy it might be a bit more sophisticated, but the
actual copying isn't exactly rocket science.

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

Now I am even more confused - a few paragraphs ago, that's exactly what y=
ou
said you wanted to be done: "not integrated into ..."   The NetBSD rc
system (/etc/rc.d) is the *only* active location in a standard system.

What is it that you really want?

I want to avoid confusing users by default.   I don't care if they have
to do a bit more work than I'd personally like to do myself (most new
admins do things in the weirdest ways to my mind anyway), but what they'r=
e
doing needs to be transparent, not deliberately obscure.

kre