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.)