Subject: Re: Summary: Third-party rc.d scripts
To: Frederick Bruckman <>
From: Shannon <>
List: tech-pkg
Date: 02/09/2002 20:23:59
On Sat, Feb 09, 2002 at 03:54:28PM -0600, Frederick Bruckman wrote:
> On Fri, 8 Feb 2002, Greg A. Woods wrote:
> > >      pkgsrc can be taught to stash an rc.d script somewhere safe before
> > >      overwriting it (/var/backups?).
> >
> > Ah, no, pkgsrc should install the original copy of the rc.d script under
> > $PREFIX/share/examples/$PKGBASE.
> I now believe, the only reasonable way to handle this, is to make sure
> the package scripts don't conflict with anything in the base scripts.
> They should have unique names, like "pkg_named", and unique rcvars, so
> you could start, say, either "named" or "pkg_named" or both, just by
> twiddling the knobs in "/etc/rc.conf". This way we're free to install
> them into "/etc/rc.d", maybe even include them in some future base system.

This sounds reasonable at first glance.

Any services you want installed multiple times couild become part of the
package configuration. Stuff like that is going to be heavily custom

I think pkg_named would also serve as a good reminder of exactly where
that service is coming from.

What about stuff put in /usr/local or /opt? If we create a package, I
assume you would think the same rules apply, giving us local_named and

If you are going to be creating your own packages anyway, then you can
also make sure things like sushi are in the loop for your system. I
guess some good examples and documentation will take care of that for
people rolling their own.

--  _________________________________________________
______________________/ armchairrocketscientistgraffitiexenstentialist
 "And in billows of might swell the Saxons before her,-- Unite, oh
 unite!  Or the billows burst o'er her!" -- Downfall of the Gael