On Thu, 15 May 2003, Frederick Bruckman wrote:

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

	I'm quite happy with the current way as it effectively defaults
	to no plus informs the user about the extra rc.d options available,
	but I would not strongly object to an explicit no.

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

	It may be worth having an option to disable the behaviour.

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

	I was thinking about it just scanning $PREFIX/share/examples/rc.d
	and /etc/rc.d and reporting on what it found. Makes it more robust
	in the case of users deleting or modifying files by hand.

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

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

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

	Those hosts would have the 'DONT_SCREW_WITH_RCD=yes' option
	set, which would not affect the generated binary packages.

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

	We would already expect the user to edit rc.conf to enable anything,
	I don't see what benefit adding additional hoops gives the average
	user. Certainly we _must_ provide options for people who want to
	do something different.

-- 
		David/absolute          -- www.netbsd.org: No hype required --