MySQL5, OS X 10.4.10, startups, etc.

[Ryan Schmidt]

On Oct 1, 2007, at 12:57, paul beard wrote:

> On 9/30/07, Ryan Schmidt wrote:
>
>> On Sep 30, 2007, at 12:18, paul beard wrote:
>>
>>> Conversely, you can add the appropriate lines to launchd.conf and  
>>> get things going.
>>>
>>> more /etc/launchd.conf
>>> launchctl  load /opt/local/etc/LaunchDaemons/org.macports.dbus/ 
>>> org.macports.dbus.p
>>> list
>>> launchctl  load /opt/local/etc/LaunchDaemons/org.macports.apache2/ 
>>> org.macports.apa
>>> che2.plist
>>> launchctl  load /opt/local/etc/LaunchDaemons/org.macports.mysql5/ 
>>> org.macports.mysq
>>> l5.plist
>>>
>>> I would vote for MacPorts to take the latter approach, with the  
>>> post-install message explaining that
>>>
>>> ########
>>> ## To get the application to run at boot time,
>>> ## echo launchctl  load /opt/local/etc/LaunchDaemons/ 
>>> org.macports.mysql5/org.macports.mysql5.plist >> /etc/launchd.conf
>>> ##
>>> ##########
>>
>> Feel free to make a proposal to the macports-dev list if you feel
>> strongly about this. The current approach works, so you should
>> explain why your approach is better (and if there are any reasons why
>> it might be worse).
>
> I don't know that I feel strongly about it. I think it preserves  
> the integrity of the host file system by editing an existing file  
> rather than writing files to places outside of /opt/local. I  
> realize that rule is bent and in some cases broken[*] but I think  
> adhering to the infrastructure where possible makes sense. Adding  
> and removing those startup items is centralized in the one file  
> that is easily found, rather than looking in the active system  
> hierarchy and risking mucking something up (imagine the consequence  
> of a poorly-formed rm command in /Library/LaunchDaemons?)
>
> * see /Library/Tcl/macports-1.0/

In the current way, the symlink is made in the destroot and handled  
just like any other file in the port's manifest. On activate, it is  
installed to the right place. On deactivate, it is removed. To start  
the service, you "launchctl load" it and to stop it, you "launchctl  
unload" it. This is all fairly easy and works.

Your way would require someone to manually edit the file /etc/ 
launchd.conf, at least to remove a line from it. That's more  
complicated than the current way, where a single launchctl line  
starts or stops the service. Also, with your way, the service  
wouldn't start or stop until the next startup. That's worse than what  
we have now, where the service starts or stops immediately.

Running a single launchctl command to start or stop a service is  
easy. Conversely, adding a line to a file is easy, as you showed, but  
removing a line from a file requires a more elaborate script. So why  
change it to make it more difficult?

There's a slight problem with the current way. If the service is  
running at the time that you uninstall the port, the software stays  
running. And if the service is running at the time that you upgrade  
the port, the old version stays running and the new version's plist  
says the software isn't running and it's inconvenient to fix that  
(manually edit the plist to show that the software is running,  
launchctl unload the software, launchctl load it again). Would your  
new way solve either of these problems? (I haven't tried so I don't  
know.)