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 and MySQL. Regards, Blair -- Blair Zajac, Ph.D. <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/