Date:        Mon, 3 Jan 2005 08:43:31 -0500 (EST)
    From:        Todd Vierling <tv@duh.org>
    Message-ID:  <Pine.NEB.4.61.0501030837100.635@server.duh.org>

  | No, it's definitely an objective.

No, what files get put where cannot really be an objective - unless your
object is to create an artwork (not necessarily any practical function,
but pleasing to the eye) what gets put where is just a detail.    Those
things all happen for some higher level purpose.

  | I'll restate it one more time.  "The admin should never have to *copy=
* files
  | into place; the packaging system should ALWAYS install and manage the=
m, even
  | if the pathname is configurable by some variable or other.  This is
  | unrelated to whether the files, once installed, must be edited for pr=
oper
  | operation."
  | =

  | Does this make it clear to you yet?

No, it doesn't.   Not that I disagree with this, but it isn't clear what
"the packaging system" is - that is, if we had a pkg_enable command, that=

would (just from its name) be a part of "the packaging system" wouldn't i=
t?
Then if it did the file copying, rather than pkg_add (or make install) th=
at
would meet your requirement, wouldn't it?

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

  | 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=EFve users".

That's what the recent change did, that was its whole purpose (whether
it has succeeded or not we will have to wait a while to find out).

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

They cannot (by default) go anywhere other than /etc/rc.d and meet the
objective of avoiding confusion.   That's (at least currently, and perhap=
s
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).

In an earlier message you said ...
  | On NetBSD, that depends on the desired integration level by the admin=
=2E  If /
  | usr is not separate from / (and in many installations, it's not anymo=
re),
  | 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=EFve users - sure, you can man=
age
it without difficulty, but you can also handle PKG_RC_SCRIPTS=3Dyes in mk=
=2Econf
and your sh environment.

What the relationship is between / and /usr isn't really relevant,
PKG_SYSCONFBASE isn't necessarily on /usr (it may be /usr/pkg but
that's not necessarily /usr) - and working "in many installations"
isn't good enough in any case, all this stuff needs to work predictably
in all of them.

So, should the default for PKG_RC_SCRIPTS change, it has to be done with
everyone's understanding that the default RCD_SCRIPTS_DIR must be
/etc/rc.d (which isn't to say that the knob to allow it to be changed
can't remain, but the default has to be the place that works).

That is, you have to convince people that pkg_add and "make install"
should (by default) install files into /etc.   Last time that was
attempted, lots of people complained - which is, I think, why the
current default is not to install the rc.d files, but to just put them
in an examples directory (which used to have a very confusing name, and
is now lots better).

kre

ps: the benefit of "lots of mount points" rather than "everything on
root" made my life much easier in the past couple of weeks - i had a syst=
em
that was (hardware) very flakey - fixed now, but it took a while to
work out what was broken.    During that time it was crashing very
frequently.   With everything mounted rw (as would be required with the
"one huge filesystem" model, the fsck time was enormous - enough that on
several occasions, the system crashed again before it was done (fortunate=
ly,
each completed fsck doesn't have to be repeated on the subsequent boot,
so it did eventually get back up to a stage where it was able to function=

enough for me to work out what was really failing).

Overcame that problem by simply making all my filesystems, except / /var
and /var/tmp (yes, I typically use several mount points under /var)
were read only essentially all the time - even /home - whenever I needed
to change something (write files) I simply made the relevant filesys read=
-write
for a minute, did the update, and put it back read-only.   After that,
fsck was just seconds at each reboot.   [Now we just need raidframe to
understand that if all the filesystems on the raid (mirror) are read only=
,
it really should remain consistent - and should put itself back into a
consistent state when writes to it stop, so mirror reconstruction isn't
required either.]

The argument against lots of filesystems - the one we used to have - was
the problem of having free space in places where it couldn't be used.
These days, that's not much of an issue any more - drives are so big
that the amount used by the netbsd related filesystems (even with lots
of room left free for growth).   That is, netbsd (binaries, sources,
packages, ...) will all fit on way < 10GB.   On a 160GB, or 200GB drive,
if you've run out of space, the extra couple of GB that's been wasted in
/usr or /usr/pkg or /var/spool or something isn't really going to be of
much help.

But for the odd cases where it is, we also now have union mounts, that
allow space to be (temporarily) put wherever it is needed, easily enough.=