Date:        Mon, 3 Jan 2005 15:37:35 +0100 (CET)
    From:        Dieter Baron <dillo@danbala.ifoer.tuwien.ac.at>
    Message-ID:  <200501031437.j03EbZP26151@danbala.tuwien.ac.at>

  |   Let me try to state my goal again: Make enabling and configuring a
  | server installed via pkgsrc as simmilar to enabling and configuring a
  | server from the base system as (reasonably) possible.

OK, that one is an objective.   There's the big question of whether or
not it is possible to make them consistent enough to bother - two things
that are almost the same, but subtly different is much worse than two
things that are wildly different.

But assuming it is possible, do be aware that when there are two objects,
and they're different, and the object is to eliminate the difference,
you can do that by changing either object, or by changing both - it isn't
good to assume that the only way is to pick one of them and require that one
to change to be like the other (that is, you'd have to justify that).

  |   So far, you have not responded to those arguments in any way.  If
  | you see flaws in these arguments, or see a reason why they do not
  | apply, please say so.  Simply repeating that you want servers to start
  | upon install is not helpful.

Mostly here I haven't been giving my opinions at all, I've just been
asking questions.   That's to make sure that everything is being
considered, and done for good reasons.

What I said (asked) was how you explain to people why installing one
package from pkgsrc (src or bin) just works, and another doesn't, and
how you can justify that.

  |   True, but that is a separate issue.

I know.   The original comment you responded to was a parenthetical remark.
But it is interesting to observe that you're asking for consistency with
a system which is internally inconsistent.   That's not a good start.

  | What would be the advantage of handling pkgsrc servers differently than
  | base system servers?

I didn't say that they needed to be different.   In fact, we could
consider de-populating /etc/rc.d - most of what is in there is never
used my most of the users, it just wastes startup time determining
that the relevant thing isn't turned on.   At the minute though, that
directory serves double purpose, it is both the home of the scripts that
are needed at startup, and the storage container for those that aren't,
but might be one day.   We could move the storage container to /usr/share/
examples/rc.d and put far fewer scripts into /etc/rc.d by default
(just those essential for the system to operate correctly).

Then (tool or no tool) we'd have base system / pkgsrc consistency, and
have met your goal, in both of them you'd need to copy the rc.d script
from the examples directory to /etc/rc.d and then enable it.

[Aside: I am not suggesting getting rid of rc.conf hand just having the
presence in the directory as th eon/off switch - that's useful functionality
quite apart from which scripts get installed in rc.d.]

  | For the kind of tools you propose, the details of how servers are
  | enabled and configured are hidden from the admin by the tool.  So why
  | do you argue against handling them the same way as is done in the base
  | system (which would simplify such a tool)?

I never argued anything like that.

kre