rc.d and ports

[Mike Makonnen]

On Tue, Feb 24, 2004 at 10:59:07AM +0100, Oliver Eikemeier wrote:
> 
> I guess I don't fully understand what modifications you suggest for the
> ports. What is needed to fit into rc.d?

The modification I ask for in my initial email :-)
If ports want to be a part of rc.d then they must use appropriate rc.d
mechanisms. My rc.d modification to support
/usr/local/etc/{rc.conf,defaults/rc.conf,rc.conf.d} are necessary
so that ports configuration knobs don't pollute the enviroment for
base system scripts.  But other than that, it should be up to the
ports to fit into the rc.d scheme.

The problem with your patch is that it is a bunch of hacks to
rc.d to semi-incorporate ports into the rc.d mechanism. My point
is: don't hack rc.d to semi-incorporate ports. Instead, we should
fully incorporate ports into rc.d.

> >>
> >>I guess we don't need this (and shouldn't do it, since 
> >>${PREFIX}/etc/defaults/rc.conf
> >>might be read-only). Defaulting xxx_enable to "NO" seems to be 
> >>sufficient, with
> >>
> >>[ -z "$xxx_enable" ] && xxx_enable="NO"
> >>or
> >>xxx_enable=${xxx_enable:-"NO"}
> >>before calling load_rc_config $name
> >
> >Again, why special-case ports scripts ?
> 
> Because the defaults belong to the port, not to the base system. I want them
> to go away with the port. Nobody (and especially not ports) should edit
> whatever/defaults/rc.conf, and how would I otherwise cope with the situation
> that default flags may change?

Then the ports can use /usr/local/etc/rc.conf.d. When the port is deleted
it can just delete the appropriate conf file in that directory without the
need to edit any files.

> 
> I guess I incorporate ${PREFIX}/etc/defaults/rc.conf and another change in
> PR 56736, the main point there was that I wanted them to participate in 
> rcorder,
> which I believe is a good thing, especially when you consider the 
> possibility
> to move sendmail or other parts of the base system to ports.
> 
> So I understand that sourcing ${PREFIX}/etc/defaults/rc.conf is the main
> reservation that you have against this patch?

No. As I have tried to state already I don't like it because it is an
unnecesary hack. As for participating in rcorder(8), first the ports
have to support all the rc.d mechanisms. Your patch simply hacks rc.d
to allow those ports that choose to use some of the rc.subr functionality
to participate in rcorder(8)ing. What should happen is that our ports
infrastructure should fully support rc.d and all ports scripts should
be modified to work with rc.d. Otherwise, we will have lots of confused
users wondering why some ports are ordered with the base system scripts and
others are not.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
mtm at identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8  5279 5359 2B82 7CD4 1F55
mtm at FreeBSD.Org| FreeBSD - Unleash the Daemon !