ports modifying system setups

[Chuck Robey]

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 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"
>>