In article <29948.1104531100@munnari.OZ.AU> Robert wrote:
:     Date:        Fri, 31 Dec 2004 01:23:07 +0100 (CET)
:     From:        Dieter Baron <dillo@danbala.ifoer.tuwien.ac.at>
:     Message-ID:  <200412310023.iBV0N7J26667@danbala.tuwien.ac.at>

:   |   ``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:

: But why is three magic?

  There is nothing magic about three.

  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.

: For me, one is what I want - when I install most packages that's exactly
: what I expect, I install this one, and having done that, it works.   But
: when I install this other one it doesn't work?   Why is that?

  Me and others have stated good reasons why installing a package
should not automatically start (or enable to run after the next
reboot) any servers installed by it.  At least not by default.

  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.

:   |   I do *not* want to have to do any more, or make any of the steps
:   | more complicated.

: Then why not make them less complicated?  Why would you demand to have
: to run an editor on rc.conf for example (I'm assuming that you're not
: proposing requiring that the editor be vi necessarily, though personally
: I wouldn't mind that...)

  I don't demand that.  Note the ``usually'' in my first sentence.

  You want a tool that enables and starts a server for you.  I have
nothing against such a tool.

   If base system and pkgsrc servers are handled in the same way, that
makes it much simpler for such a tool to handle both cases.  (Which is
one reason why I think they should be handled the same way; the other
main reason is that admins only have to learn/remember one method.)

:   | And, with the exception of installing, this is
:   | exactly what I do to enable a server that is part of the base system.

: But that exception is what makes the base system different/

  Yes, but that is no reason to add aditional differences.

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

: No, you misunderstood my remark.   I meant the two (perhaps more) different
: ways to enable servers in the base system (not meaning pkgsrc at all).
: That is, for some servers one is required to edit rc.conf (and then run
: the rc.d script - or reboot).   For other servers one edits inetd.conf,
: and then runs a totally unrelated rc.d script (or kills (sends a signal to)
: a mysterious process - or reboots).    That difference is annoying,
: especially when it relates to two different instances of the same basic
: command - take web servers, apache wants an rc.d script (I believe),
: bozohttpd wants inetd.conf.

: Wouldn't it be nice to just be able to say "enable bozohttpd" or "enable
: apache" or "enable ftpd" or "enable sshd" and have it do whatever is
: appropriate for that particular server?

  True, but that is a separate issue.  If a tool to enable servers
were tought to handle rc.d started and inetd started servers, it could
then handle both types of servers from both the base system and rc.d.
And after all, if you don't want to have to know if the server is rc.d
or inetd started, wouldn't it be nice if you didn't have to know if it
came from pkgsrc or the base system either?

:    Which in the pkgsrc case, could,
: sometimes, include coping an rc.d file from one place to another, if it
: wasn't already present where required, couldn't it?

  You are proposing additional complexity that such a tool (and, more
importantly, an admin that chooses not to use such an (as yet
non-existant) tool) would have to handle.  For what purpose?  What
would be the advantage of handling pkgsrc servers differently than
base system servers?

  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)?  Me and others have stated
at length why we think it would be a good idea.  Could you please
state why you don't, and what you think is bad about it?

						yours,
						dillo