>> So one way of dealing with this would be to provide an oldfashioned >> script. But where to put that. I would be tempted to put it into >> /opt/local/init.d/, >> but there is nothing yet. > > Well, I'm not an experienced Ports developer, so I don't know what's the > rigth way. But I don't like the idea to create a new method to start things. > A Script StartupItem would do the same. (5.7.3 in the guide). The > StartupItems from the original package provide already some scripts and the > PID issue could be solved by setting "startupitem.pidfile" to "none"
yeah you could probably hack it, but the guide is quite clear here: A StartupItem is a MacPorts facility to run "daemons," a Unix term for programs that run continuously in the background, rather than under the direct control of a user;" I would not like to duplicate code either, obviously, but also not violate things. It is true though, IIRC, that StartupItems are meant to do more than managing daemons. But I don't know if MP startupitem facilities have stricter assumptions. And this above sounds much like it. Or the guide author was actually a bit too restrictive in his description and nothing is wrong with your approach. I don't know. The only other port that mentions "kext" is macfuse, according to rgrep. And that contains a Framework, and I would imagine that places the kext into a well-known place and takes care of everything. And least it has no special means to start it. > Another problem could be a conflict with an already installed Kext (maybe > the legacy TUN/TAP driver or Tunnelblick). MacPorts does not overwrite files but rather fails before doing so. And then you just have to know how you manually configured your system. What is the "legacy TUN/TAP" btw? Florian -- Florian Ebeling [EMAIL PROTECTED] _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev