>   |   ``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 perfor=
m:
>
> But why is three magic?
>
> For me, one is what I want - when I install most packages that's exac=
tly
> 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?

It's not about magic, but I expect it's about us not wanting to
automatically enable a service, possibly provided to other systems,
and possibly exposing the installed system to a security threat
without explicit administrator action.

Please remember as earlier stated in this thread -- usually many
packages are added purely as dependencies, but actual usage may not
depend on any services provided by the pulled-in packages.
Atomatically enabling all such services from pulled-in packages would
lead to a higher exposure to security threats than needed or desired.

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

Yes, but that's icing on the cake, and solving this would require more
"infrastructure" design, and code both in the base system and in
pkgsrc.  My suggestion would be to first get a fix so that users can
avoid unexpected manual actions to enable a service, and get the rc.d
and configuration files installed somewhere reasonable by default.

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

To my mind, copying the rc.d file in it's proper place should be part
of the "install" phase, while actually enabling the service would be a
separate step.  In the "install" phase, all the files used by the
package are installed, registered in the "which files belong to which
package" database, and all these files are removed on deinstallation.
Having a separate "enable" step installing files would, I think, make
the maintenance of the "which files belong to this package" database
more complicated.

Regards,

- H=E5vard