Re: rc.d and ports
From: Oliver Eikemeier (eikemeier_at_fillmore-labs.com)
Date: 02/24/04
- Previous message: Mike Makonnen: "Re: rc.d and ports"
- In reply to: Mike Makonnen: "Re: rc.d and ports"
- Next in thread: Mike Makonnen: "Re: rc.d and ports"
- Reply: Mike Makonnen: "Re: rc.d and ports"
- Reply: David O'Brien: "Re: rc.d and ports"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 24 Feb 2004 10:59:07 +0100 To: Mike Makonnen <mtm@identd.net>
Mike Makonnen wrote:
> On Mon, Feb 23, 2004 at 11:46:23AM +0100, Oliver Eikemeier wrote:
>
>>Mike Makonnen wrote:
>>
>>>Hi,
>>>
>>>A lot of people have been calling to have ports startup scripts
>>>integrated into rc.d. I have finally gotten arround to doing it.
>>>Attached are the rc.d patches to make it work, but
>>>I will need some cooperation from the ports folks.
>>
>>See PR 56736, there since Sep 2003:
>> <http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/56736>
>>
>>If you don't like it, please provide feedback what you think can be
>>improved.
>
> It looks like you put some effort into it and I appreciate it, but
> I'm sorry to say I don't like it at all. It really isn't any better than
> the current situation. Basically your patches special case the ports
> scripts and hack around rc.d mechanisms to make it
> work with ports. This is wrong. If anything the ports should
> be modified to fit in the already present rc.d mechanism.
I guess I don't fully understand what modifications you suggest for the
ports. What is needed to fit into rc.d?
>>>The makefile for the port should define a variable:
>>>
>>>RCVAR_NAME="fooport_enable"
>>>
>>>Then, logic similar to this should be inserted in the appropriate
>>>bsd.port* makefile:
>>>
>>>if ! grep 1>/dev/null "\$${RCVAR_NAME}=" ${PREFIX}/etc/defaults/rc.conf ;
>>>then
>>> echo "${RCVAR_NAME}=NO" >> ${PREFIX}/etc/defaults/rc.conf
>>>fi
>>
>>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?
> If the only thing people want is an xxx_enable, then the current scheme
> is fine: Install the port script with xxx.sh-sample and when you want
> to enable it just rename the file. But if the ports want to be able to
> use the whole range of rc.d functionality, then ${PREFIX}/etc/defaults/rc.conf
> is needed for all the other knobs that need to be defined.
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?
Regards
Oliver
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Mike Makonnen: "Re: rc.d and ports"
- In reply to: Mike Makonnen: "Re: rc.d and ports"
- Next in thread: Mike Makonnen: "Re: rc.d and ports"
- Reply: Mike Makonnen: "Re: rc.d and ports"
- Reply: David O'Brien: "Re: rc.d and ports"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
