ports modifying system setups

[Naram Qashat]

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.

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 at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>>> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
>>>
> 
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
>