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.
<[EMAIL PROTECTED]>
Subversion training, consulting and support
http://www.orcaware.com/svn/
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
