<br><br><div><span class="gmail_quote">On 10/1/07, <b class="gmail_sendername">Ryan Schmidt</b> &lt;<a href="mailto:ryandesign@macports.org">ryandesign@macports.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>In the current way, the symlink is made in the destroot and handled<br>just like any other file in the port&#39;s manifest. On activate, it is<br>installed to the right place. On deactivate, it is removed. To start<br>
the service, you &quot;launchctl load&quot; it and to stop it, you &quot;launchctl<br>unload&quot; it. This is all fairly easy and works.</blockquote><div><br class="webkit-block-placeholder"></div><div>This assumes that people deactivate or otherwise that allow MacPorts to clean up after itself. rm -rf /opt/local would leave those broken symlinks. They don&#39;t really matter but as I said earlier, the &quot;nothing outside /opt/local&quot; rule is bent in some cases, this being one.&nbsp;
</div><div><br class="webkit-block-placeholder"></div><div>And as for invoking launchct load statements, how is this different?&nbsp;</div><div><br class="webkit-block-placeholder"></div><div>launchctl &nbsp;load /opt/local/etc/LaunchDaemons/org.macports.dbus/org.macports.dbus.plist&nbsp;
</div><div>launchctl &nbsp;load /opt/local/etc/LaunchDaemons/org.macports.apache2/org.macports.apache2.plist&nbsp;</div><div>launchctl &nbsp;load /opt/local/etc/LaunchDaemons/org.macports.mysql5/org.macports.mysql5.plist&nbsp;</div><div>&nbsp;</div>
<div>from putting the plists in launchd&#39;s default search path? As configured, launchctl looks in two places for plists: in /System/Library/LaunchDaemons, for Apple-owned stuff, in /Library/LaunchDaemons for user-installed/third-party stuff. I don&#39;t see a big deal about another repository for plists. Maybe in future releases launchd will allow additional directories to be added instead of individual lines.&nbsp;
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Your way would require someone to manually edit the file /etc/<br>launchd.conf, at least to remove a line from it. That&#39;s more
<br>complicated than the current way, where a single launchctl line<br>starts or stops the service. Also, with your way, the service<br>wouldn&#39;t start or stop until the next startup. That&#39;s worse than what<br>we have now, where the service starts or stops immediately.
</blockquote><div><br class="webkit-block-placeholder"></div><div>see above: if launchctl works as it says on the tin, there is not different between symlinks that point to /Library/LaunchDaemons and the lines I have in /etc/launchd.conf. &nbsp;
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Running a single launchctl command to start or stop a service is<br>easy. Conversely, adding a line to a file is easy, as you showed, but
<br>removing a line from a file requires a more elaborate script. So why<br>change it to make it more difficult?</blockquote><div><br class="webkit-block-placeholder"></div><div>I&#39;m not arguing in favor of it. I&#39;m just explaining it. &nbsp;I have a hard time believing that, given the power on tap, that there is no way to add a commented line to /etc/launchd.conf&nbsp;
</div><div><br class="webkit-block-placeholder"></div><div><div>launchctl &nbsp;load /opt/local/etc/LaunchDaemons/org.macports.dbus/org.macports.dbus.plist # installed by macports</div><div><br>&nbsp;</div><div>and add a # character to the beginning of the line containing the comment:
</div><div><br class="webkit-block-placeholder"></div><div>sed -e s/^launchctl/#&amp;/g &lt;- &nbsp;yes, I know that won&#39;t work, but you get the idea: sed is not my native language.&nbsp;</div><div><br>&nbsp;</div></div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
There&#39;s a slight problem with the current way. If the service is<br>running at the time that you uninstall the port, the software stays<br>running. And if the service is running at the time that you upgrade<br>the port, the old version stays running and the new version&#39;s plist
<br>says the software isn&#39;t running and it&#39;s inconvenient to fix that<br>(manually edit the plist to show that the software is running,<br>launchctl unload the software, launchctl load it again). Would your<br>new way solve either of these problems? (I haven&#39;t tried so I don&#39;t
<br>know.)</blockquote><div><br class="webkit-block-placeholder"></div><div>Is there no pre-install step that could stop the service with the existing plist, install, restart? &nbsp;</div></div><br clear="all">Again, I&#39;m not arguing in favor of doing it this way, I&#39;m just explaining it. Perhaps if it&#39;s more clearly understood, a comparison can be made.&nbsp;
<br>-- <br>Paul Beard / <a href="http://www.paulbeard.org/">www.paulbeard.org/</a><br>&lt;<a href="http://paulbeard@gmail.com/paulbeard@mac.com">paulbeard@gmail.com/paulbeard@mac.com</a>&gt;<br>