[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: postinstall wiped out my /etc/rc changes
On Mon, 5 May 2008 04:26:03 am Greg A. Woods; Planix, Inc. wrote:
> On 3-May-08, at 1:04 PM, Daniel Horecki wrote:
> > And what with rc.d/ files? E.g. I have xdm from pkgsrc, and every time
> > I had to use postinstall,
> > I have to to bring back that files.
> As others have said, the correct way for a package to override a
> "standard" rc.d script would be to create an rc.conf.d script that
> will adjust the necessary pathnames appropriately so that the package
> variant is used instead of the original base-OS variant. In my
> opinion that's what pkgsrc should be doing for NetBSD whenever it
> provides a package that is already part of a base system install.
> I've modified pkgsrc to do that for some of the packages I install,
> such as bind9.
> In general though properly conforming pkgsrc packages will always
> install their rc.d script into /usr/pkg/share/examples/rc.d and then
> IFF there is not a script of the same name in /etc the install
> procedure will then copy it into /etc/rc.
> So: (a) you've always got the original package's rc.d script to
> compare or copy if the system upgrade messes something up; and (b) the
> package install should never automatically override an already
> installed rc.d script regardless of whether that script was supplied
> by the system or another package; and (c) for all system-supplied rc.d
> scripts it is possible to override the command and parameters used to
> invoke the daemon or whatever such that a variant installed by a
> package can be used instead of the base-OS variant.
And I can't see any other way that would not impose some assumptions on the
user except for the suggestion of making the process clearer.
A mk.conf variable for the creation of rc.conf.d overrides provided by pkgsrc
may be useful. This would give the user the ability to state that pkgsrc
versions should override the system provided ones and shouldn't effect an
etcupdate. Maybe the same can be applied to mail.conf ... Just a thought.
Main Index |
Thread Index |