blair at orcaware.com
Sat Mar 3 23:47:51 PST 2007
James Berry wrote:
> On Mar 3, 2007, at 1:48 AM, Randall Wood wrote:
>> Is this +no_startupitem variant really smart?
>> I recently had a request to add a +without_startupitem variant to a
>> port I maintain and rejected the request; since startupitems simply
>> enable a port to be started at boot time, but do not cause a port to
>> be booted at start time, it simply seems stupid to deliberately
>> cripple a server port such that a user would have to reinstall it if
>> they wanted to start the port at boot time later.
>> BTW: If the variant is to be retained, can it be named
>> +without_startupitem instead?
> Unless I'm missing something, I see no reason whatsoever for the
> no_startupitem variant, or anything like it.
> Using the startup item strategy, we have two cases, systemstarter (pre
> tiger) and launchd (tiger++):
> SystemStarter: The code generated by port for system starter
> automatically looks for an enable flag from /etc/hostconfig, and this is
> -NO- by default. So by default the port won't be run.
> Launchd: Likewise, the launchd.plist file generated for a port is not
> enabled by default, so by default the server won't be run.
> The only reason I see for having a +server variant in some cases is if
> building the server is way too onerous (like perhaps in the case of
> mysql where somebody just wants to build the client but not the server).
> Still this is debatable.
I still don't need that stuff installed on the system at all for this
use of MacPorts, even if it isn't enabled by default.
Definitely not a standard use of MacPorts, but I have a client that
ships Firewire/USB drives with a MacPorts install in /Volumes/SOMENAME/.
People plugin in the drive, launch a Python app which starts Apache
Blair Zajac, Ph.D.
<blair at orcaware.com>
Subversion training, consulting and support
More information about the macports-dev