[First off, please leave enough context so it's clear what I was
answering to.  In some places that was hard even for me to see, and I
wrote the text today.]

In article <19649.1104439143@munnari.OZ.AU> Robert wrote:
:   | * install package (make install or pkg_add)
:   | * explicitly enable server (add a line to rc.conf (e.g. server=YES))
:   | * optionally override default settings in rc.conf (e.g. server_flags=--foo)
:   | * start server (/etc/rc.d/server start)

: You're willing (and what's more, wanting) to do all of that work, and
: you're not willing to copy a file (or set an env var / mk.conf var to cause
: the copy to happen for you) ?   That's an interesting place to draw the line.

  ``All of that work'' usually consist of three commands:

pkg_add (or make install)
vi /etc/rc.conf
.../rc.d/foo start

  Which corresponds exactly to the three actions I want to perform:

- install package
- enable server
- start server

  I do *not* want to have to do any more, or make any of the steps
more complicated.  And, with the exception of installing, this is
exactly what I do to enable a server that is part of the base system.

:   | much in the same way as is done for servers in the base system.

: The two cases are not the same at all.   Stuff in the base system gets
: installed whether I want it or not - I don't ask for a ftp server, or
: a MTA, or ...  they're just dumped on me.   So, for those, it is both
: reasonable, and easy to understand, that the server needs to be explicitly
: enabled before it works

  It is also reasonable that the servers installed via pkgsrc need to
be explicitly enabled: as others and I have noted, there are packages
that install more than just a server.  Some install two or more
servers, some install a server and a client (or client library).
Simply because I need part of that package (and thus install it),
doesn't mean I want all of it's servers running.

: (it is less easy to justify that some servers
: get enabled in one way, and others in an entirely different way, but that's
: not the issue now).

  No, that is *exactly* the issue!  Servers in the base system and
servers from pkgsrc should be enabled in the same way.

: On the other hand, if I am explicitly installing apache, or cups, or ...
: surely I want to use the thing, why else would I be installing it?

  Because some program needs the cups client libraries?

[pkg_enable proposal (context (too) liberally culled)]
:   |   That might have a more complex semantic than you imply.  What about
:   | packages that provide more than one server, for instance?

: SMOP.    That's not hard at all.

  No, it's a not quite so simple matter of interface design: How do I
specify which of the possibly multiple servers the package provides I
want to start?  We already have a method to specify which servers to
start (edit rc.d), why invent a new one?

[pkgsrc rc.d scripts have to be on root file system]
:   |   Why?  They can't be run before $LOCALBASE is mounted anyway (as the
:   | servers they are trying to start reside there),

: No, but the run order gets determined before anything else is done,
: for packages that are, and are not, on filesystems mounted at boot
: time (ie: for those that are on root, and all the others).

  True.  Which leaves us two ways of dealing with it: either place
pkgsrc rc.d scripts on the root file system, or enable the rc
subsystem to recalculate the order after reading in the additional
rc.d scripts.  Both are fine with me.

:   | so I don't see the
:   | technical necessity of having to read them before then.  (Yes, I am
:   | aware that the rc subsystem is currently unable to handle this, but
:   | that could be fixed.)

: "Could be fixed" - fix this one first, then we'll talk about it.

  I'd prefer that we discuss what is wanted and then implement it.
And yes, I'm willing to work on it.