Date: Mon, 19 Nov 2007 15:02:41 -0500 From: Chuck Robey <chuckr@chuckr.org> To: Naram Qashat <cyberbotx@cyberbotx.com> Cc: FreeBSD-ports@FreeBSD.org Subject: Re: ports modifying system setups Message-ID: <4741EBE1.4080502@chuckr.org> In-Reply-To: <4741E966.1090601@cyberbotx.com> References: <4740E430.9050901@chuckr.org> <47410380.5080406@cyberbotx.com> <4741E3E3.7060808@chuckr.org> <4741E966.1090601@cyberbotx.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Naram Qashat wrote:
> In the pkgtools.conf file that portupgrade installs, there's two
> sections, BEFOREINSTALL and AFTERINSTALL. In BEFOREINSTALL, you could
> put the following in to make it try to stop the service if there's an rc
> script for the port:
>
> '*' => proc { |origin| cmd_stop_rc(origin) }
>
> And almost the same thing for AFTERINSTALL, except cmd_start_rc instead
> of cmd_stop_rc. And as long as the line for that service is in
> /etc/rc.conf, it'll start or stop via the rc script. It even says that
> in the comments of pkgtools.conf.
Ah, you misunderstood me. I was never saying, or meaning, that ports
could not do it, I was saying they did not do it, no one I have seen
implemented that behavior. Yes, you're certainly right, they can,
they've had the ability all along.
>
> Naram Qashat
>
> Chuck Robey wrote:
>> Naram Qashat wrote:
>>> Also a good thing to point out is that portupgrade can be configured
>>> to automatically start or stop a port's daemon via it's
>>> /usr/local/etc/rc.d script, which still relies on having the
>>> appropriate line in /etc/rc.conf to tell the rc.d script to run, but
>>> it is helpful for upgrading ports which have daemons so they can be
>>> shut down and then started again after the upgrade is complete.
>>
>> Not sure I understand what you mean here. I *think* I remember that
>> ports (quoite a while back) did not require any patching of rc.conf at
>> all, just coding in /usr/local/etc/rc.d. Nowadays, there are required
>> lines in rc.conf which fire sections of rc.d, but apparently (and i do
>> approve of this) the /etc/rc.conf can't be touched. I guess I don't
>> understand why not have the entire startup code in rc.d, and merely
>> have rc source in rc.d after it's finished with rc.conf.
>>
>> I just took a good long look at portupgrade, I didn't see any option
>> like you're talking about. You understand, there is no reason that
>> ports couldn't do what I'm asking about. They aren't written to do
>> this (at least, several different daemon-ports that I've installed
>> all required manual patching of rc.conf). This isn't just my own
>> interpretation, because the ports themselves hint to the user that
>> they should patch rc.conf to get the port working as a daemon.
>>
>> I'm just saying that ports should be written to handle this
>> themselves, and not to require manual patching to get this done. One
>> reason would be users (non-technical ones) who install a particular
>> port as a dependency, and thus never even see the comments about what
>> they should do to get things working. I can't see any reason NOT to
>> do this, and good reason why it should be done.
>>
>>>
>>> Naram Qashat
>>>
>>> Chuck Robey wrote:
>>>> I was wondering why ports apparently aren't allowed an obvious
>>>> freedom, that of being able to set themselves to run as daemons. A
>>>> greate long time past, I seem to remember that there used to be a
>>>> file /usr/local/etc/rc.local, which (if it existed) would be
>>>> automatically sourced in at the end of rc.conf. Ports which built
>>>> daemons were allowed (well, actually, expected) to ask the user if
>>>> they wished to activate the port, and if so, the port would add a
>>>> line of the form 'portname_enable="YES"', and this would make your
>>>> new port operate. Well, it seems from what I see of my new system,
>>>> that this is no longer the case. I could understand (and approve
>>>> of) ports not being allowed to modify any /etc/contents, but howcome
>>>> ports can't use this rather obvious workaround?
>>>>
>>>> I'm pretty sure this used to be allowed... and it seems like a good
>>>> policy to me, from the number of non-technical folks who now run
>>>> FreeBSD. I just wanted to know why its not anymore.
>>>> __
>>
>>
>>
>> _____________________________________________
>>>> freebsd-ports@freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>>>> To unsubscribe, send any mail to
>>>> "freebsd-ports-unsubscribe@freebsd.org"
>>>>
>>
>> _______________________________________________
>> freebsd-ports@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
>>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4741EBE1.4080502>