#36770 closed defect (fixed)
Need for a fix regarding mechanism for startupitem handling
Reported by: | mkae (Marko Käning) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | MacPorts 2.5.0 |
Component: | base | Version: | 2.1.2 |
Keywords: | Cc: | pixilla (Bradley Giesbrecht), ryandesign (Ryan Carsten Schmidt), kurthindenburg (Kurt Hindenburg) | |
Port: |
Description
There are two configuration parameters handling one and the same thing:
1) startupitem_type (which could be set to "none")
2) startupitem.install (which could be set to "no")
It now depends on the individual port whether it would install a startup item or not. (See #36749)
Change History (14)
comment:1 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
comment:2 Changed 12 years ago by mkae (Marko Käning)
Yes, I agree it's best to remove startupitem_type
in that case.
This should be done by a MacPorts base maintainer, since I have no idea what else might be involved here.
comment:3 Changed 7 years ago by kurthindenburg (Kurt Hindenburg)
Cc: | kurthindenburg added |
---|
Is it still the plan to remove startupitem_type? If so, I can work on a patch. There's a lot of code in portstartupitem.tcl that would need removed if SystemStarter is no longer needed.
comment:4 Changed 7 years ago by raimue (Rainer Müller)
OS X 10.4 Tiger introduced launchd. This is also the oldest macOS release that base will still work on, therefore SystemStarter can and should be removed.
As we would only have a single type, startupitem_type
can be removed as well. We can always reintroduce it later if needed.
comment:5 Changed 7 years ago by kurthindenburg (Kurt Hindenburg)
What about rcng? It is the default on non-darwin systems.
comment:6 Changed 7 years ago by raimue (Rainer Müller)
I don't think we need rcng any longer. The sourced ${prefix}/etc/rc.subr
does not exist anyway and I am also not aware of any port providing that file. Let's get rid of rcng.
comment:7 Changed 7 years ago by Kurt Hindenburg <kurt.hindenburg@…>
comment:8 Changed 7 years ago by Kurt Hindenburg <kurt.hindenburg@…>
comment:9 Changed 7 years ago by Kurt Hindenburg <kurt.hindenburg@…>
comment:10 Changed 7 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:11 Changed 7 years ago by jmroot (Joshua Root)
Milestone: | → MacPorts Future |
---|
These two options will be further differentiated as part of the fix for #44496.
comment:12 Changed 7 years ago by neverpanic (Clemens Lang)
Milestone: | MacPorts Future → MacPorts 2.5.0 |
---|
comment:13 Changed 7 years ago by neverpanic (Clemens Lang)
Milestone: | MacPorts 2.5.0 → MacPorts Future |
---|
comment:14 Changed 7 years ago by jmroot (Joshua Root)
Milestone: | MacPorts Future → MacPorts 2.5.0 |
---|
They aren't handling the same thing, but I agree one of them could be removed.
startupitem_type
is a setting users can set in macports.conf to indicate what type of startupitem they want a port that installs a startupitem to install. The default ever since Tiger (the oldest OS X version MacPorts now supports) is "launchd" which installs a launchd plist in /Library/LaunchDaemons. The other option is "systemstarter" which installs a script in /Library/StartupItems but there is no reason why anyone would want to do this today and we should remove this capability from MacPorts. Finally, this can be set to "none", and historically, this was what you did on secondary MacPorts installations or in other circumstances when for whatever reason you did not want startupitems installed.When startupitem_type is launchd, in fact MacPorts doesn't install the plist directly in /Library/LaunchDaemons; rather, it installs it in ${prefix}/etc/LaunchDaemons/org.macports.${name} and then makes a symlink to it in /Library/LaunchDaemons.
startupitem_install
is a new setting available in recent MacPorts versions, which lets a user indicate that they do not want that symlink to be created. This is probably the setting we should keep, and removestartupitem_type
.