On Fri, 16 May 2003, David Brownlee wrote:

> On Thu, 15 May 2003, Frederick Bruckman wrote:
>
> > > 	One thought on how to handle conflicts with original rc.d scriptss
> > > 	(eg: ssh)
> > > 	  - On install move original to /etc/rc.d/orig/ & install new script
> > > 	  - Revert on deletion
> >
> > That could bite somebody, too. Someone who'd switched to say, package
> > "ssh" because of security aspersions, might be very upset to find the
> > ghost of the old script coming back to life while he's in the process
> > of updating the package.
>
> 	Hmm. I still think its reasonable behaviour - if you delete a
> 	package you would expect the system to revert to its pre-package
> 	state.

I did too, at first, but now I'm not so sure. Note, my suggestion,
repeated below, avoids the problem completely.

> > Another possibility would be to simply choose unique names for the
> > pacakge scripts, like "bind9" or "bind9-pkg". There can't be that many
> > that overlap, anyhow.
>
> 	It prevents us from providing a simple 'drop in' replacement
> 	of system scripts with package ones.

It's still very simple. Recall the original post that kicked off
this thread. (The poster was running the wrong daemon for months).
If the message had said,

   "To start the "sshd" daemon supplied by this package at
    boot-time, add ``opensshd-pkg=YES'' to "/etc/rc.conf".
    Then, you may run ``/etc/rc.d/opensshd-pkg start'' to
    start it immediately."

the user would never have been confused about which daemon were
running. Observe the advantages over other alternatives:

1) There's no obstacle to copying everything into "/etc/rc.d", even
on bulk building machines. Conceptually, all the scripts live there
anyhow, even if they're not always installed on every single machine
(although we could still leave a knob for that step).

2) There's exactly one file to edit, and one command to start, any
daemon. The user has complete control. If the new package doesn't fly,
the user can switch back to the base daemon with a few keystrokes.

3) No changes required to the package tools, and no variations in
pkgsrc to support. (All the variables will still be available for
people who wish to hack pkgsrc internals, but we won't have any
need to document, nor to explain the hacks to new users.)

Frederick