<div dir="ltr">Just to make a confirmation on this old thread.<div><br></div><div>I reinstalled my Mac with only one partition at daemon are starting right away.</div><div>As the matter is mostly Apple, I think what's important is mostly issue a warning if at a moment (port update/selfupdate/sync/upgrade) we detect than /opt is not on /</div>
<div><br></div><div>Didn't try PathState to ensure it is working as we expected.</div><div><br></div><div>Cheers</div><div><br></div><div>Julien<br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-07 6:33 GMT-04:00 Ryan Schmidt <span dir="ltr"><<a href="mailto:ryandesign@macports.org" target="_blank">ryandesign@macports.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
On May 5, 2014, at 19:08, Eric Gallager wrote:<br>
<br>
> If you want to try modifying the launchd sources, you might want to<br>
> have a look at the openlaunchd fork of it, as it seems to be more<br>
> up-to-date than the version on <a href="http://opensource.apple.com" target="_blank">opensource.apple.com</a> at least:<br>
> <a href="https://github.com/rtyler/openlaunchd" target="_blank">https://github.com/rtyler/openlaunchd</a><br>
<br>
</div>I don’t think modifying the launchd sources is going to be a satisfying resolution to this issue.<br>
It’s the first process the OS starts, so it’s highly important it works correctly. I don’t want to be responsible for introducing a problem into that mechanism.<br>
Getting any change in that process is likely a major QA testing issue as well.<br>
And any change we might be able to get approved would be unlikely to ever make its way to older OS X versions.<br>
<br>
I would rather look for a way to fix this in MacPorts.<br>
<br>
If it is the case that launchd requires the disk on which the plist lives to be available at boot time, and if a secondary volume that MacPorts might be installed on won’t necessarily get mounted in time by launchd, then we should modify MacPorts’ strategy to accommodate that.<br>
<br>
For example, instead of installing a symlink to the plist to /Library/LaunchDaemons, we could install the actual plist file. I think we used to do this, and I don’t know why we changed to installing a symlink, and putting the real file in the MacPorts prefix, other than perhaps a thought that it was tidier. But if it doesn’t actually work reliably, tidyness is irrelevant; it needs to function correctly first.<br>
<br>
Then, we could modify the plist to use the PathState key to ensure the MacPorts prefix exists before the OS tries to start any programs living there:<br></blockquote><div><br></div><div> </div></div></div></div></div>