Just to make a confirmation on this old thread. I reinstalled my Mac with only one partition at daemon are starting right away. 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 /
Didn't try PathState to ensure it is working as we expected. Cheers Julien 2014-05-07 6:33 GMT-04:00 Ryan Schmidt <[email protected]>: > > On May 5, 2014, at 19:08, Eric Gallager wrote: > > > If you want to try modifying the launchd sources, you might want to > > have a look at the openlaunchd fork of it, as it seems to be more > > up-to-date than the version on opensource.apple.com at least: > > https://github.com/rtyler/openlaunchd > > I don’t think modifying the launchd sources is going to be a satisfying > resolution to this issue. > 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. > Getting any change in that process is likely a major QA testing issue as > well. > And any change we might be able to get approved would be unlikely to ever > make its way to older OS X versions. > > I would rather look for a way to fix this in MacPorts. > > 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. > > 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. > > 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: >
_______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
