On Thu, 15 May 2003, David Brownlee wrote:

> On Wed, 14 May 2003, Frederick Bruckman wrote:
>
> > I have a few problems with setting PKG_RCD_SCRIPTS to yes. A few
> > package scripts are still broken, and don't check the setting of a
> > variable. Those could probably be fixed in a single sweep. Fixing that
> > would make it a lot more acceptable, but even with that, there's still
> > those annoying name space collisions. Finally, the implementation
> > delete scripts from "/etc/rc.d", under some circumstances, when the
> > package is deleted, which I find really annoying.
>
> 	Namespace collisions between packages or packages and the base
> 	system?

I meant collisions between system supplied rc.d scripts and package
rc.d scripts.

> 	Would you consider packages deleting rc.d scripts if they
> 	had not been modified from the installed copy as reasonable.

That's what it does now, and I think its bogus. I'd rather manage
"/etc" all by myself, thanks.

> > > > This entire topic has been discussed to death on the appropriate
> > > > lists, and it's not even on topic here. Our shame is that we've layed
> > > > out 100,000 options, rather than coming to a decision to give users
> > > > one recommended way.
> > >
> > > 	It might make sense to try to list the useful options, then
> > > 	provide just those, in a clearly documented way.
> >
> > I really think we should nix most of them. If we choose the "right"
> > solution, when a new user asks how to do it, we can give him a brief
> > outline, point him to the documentation, and that will end the
> > discussion. If we choose the wrong one, or simply document the lack
> > of consensus, he'll want to talk about it, and that'll just start the
> > whole argument all over again, and again.
>
> 	Agreed (probably). We should have a single recommended way,
> 	and then a small set of tunable aspects for those who want to
> 	do something different (more for it to get out of their way).
>
> 	So, if we wanted to automate 'everything':
> 	  - Default PKG_RCD_SCRIPTS=yes
> 	  - All pkg rc.d scripts must contain an identifying tag
> 	  - No pkg rc.d script runs _anything_ without a rc.conf var=yes

Yes. lukem suggested we set the default to "no", in the script, before
sourcing "/etc/rc.subr". I think we should just do that.

> 	  - rc.d scripts deleted on pkg deletion if they were unchanged
> 	    from the original

I don't really like that, but I'd go along with the consensus. The
scenario was, I was switching to a custom build in "/usr/local" from
"/usr/pkg" for some particular thing, and when I went to change the
path in the scripts I was dismayed to find they'd disappeared. (Good
thing for "/var/backups/etc/rc.d".)

> 	  - Provide some pkg_XXX command or option to list the current
> 	    installed package scripts, including indicating which have
> 	    been modified and potentially orphaned (particularly useful
> 	    if it tried to handle conflicts - see next

That's an interesting idea. I guess it would call for another tag
(@rcd) and another database, and...  Or we could just install a script
to ${PREFIX}/share/etc/rc.d, tell the user to copy it himself, and let
"etcupdate" and "/etc/daily"  help handle the conflicts and history
and so on.

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

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.

I've thought about this, and if people really want that first
step automated, smashing over the previous script isn't completely
intolerable. It's mostly what you want, and you do have the backup
in "/var/backups/etc". It will require careful handling to build a
package on one host to run an another, not to mention doing something
special for the bulk builder hosts.

All in all, though, I think it would make the most sense to simply
install the rendered scripts to one place, and tell the user he's
supposed to copy it into place to activate it. The concept that "/etc"
belongs to the user is something we can all understand, and it's the
NetBSD way to give the user enough credit, to expect him to be able to
copy files and use an editor.

Frederick