startupitem.inetdcompat or newbie base hacking!
I think it would be desirable to have a startupitem that supports inetdcompatibility in MacPorts. It seems to me it wouldn't be that hard since the heavy lifting was already done in MP 1.2. So I've hacked the portstartupitem.tcl file for some new startupitems and I want to test it so I tried replacing the current copy in ${prefix} with the modified file but it isn't recognizing my new variables. What is the proper way to test a new portstartupitem.tcl file? Mark
Mark, On Apr 21, 2007, at 7:23 PM, markd@macports.org wrote:
I think it would be desirable to have a startupitem that supports inetdcompatibility in MacPorts. It seems to me it wouldn't be that hard since the heavy lifting was already done in MP 1.2. So I've hacked the portstartupitem.tcl file for some new startupitems and I want to test it so I tried replacing the current copy in ${prefix} with the modified file but it isn't recognizing my new variables. What is the proper way to test a new portstartupitem.tcl file?
Great idea to work on that stuff a bit more. Modifying the code in $ {prefix} is the right thing to do. I'm not sure which variables you're having trouble with, but one thing to be aware of is that the option variables for startupitem are declared in portdestroot.tcl. James
James Berry <jberry@macports.org> on Saturday, April 21, 2007 at 7:45 PM -0800 wrote:
I think it would be desirable to have a startupitem that supports inetdcompatibility in MacPorts. It seems to me it wouldn't be that hard since the heavy lifting was already done in MP 1.2. So I've hacked the portstartupitem.tcl file for some new startupitems and I want to test it so I tried replacing the current copy in ${prefix} with the modified file but it isn't recognizing my new variables. What is the proper way to test a new portstartupitem.tcl file?
Great idea to work on that stuff a bit more. Modifying the code in $ {prefix} is the right thing to do. I'm not sure which variables you're having trouble with, but one thing to be aware of is that the option variables for startupitem are declared in portdestroot.tcl.
Oh I see. I'll look at that. I am defining a startupitem.inetdcompat keyword and I only have it defined in portstartupitems.tcl. But 'port install' chokes on my new keyword right away and not at destroot so I wonder if that is the problem yet. So /opt/local/sharedarwinports/Tcl/port1.0 is what gets executed correct? Mark
James Berry <jberry@macports.org> on Saturday, April 21, 2007 at 7:45 PM -0800 wrote:
I think it would be desirable to have a startupitem that supports inetdcompatibility in MacPorts. It seems to me it wouldn't be that hard since the heavy lifting was already done in MP 1.2. So I've hacked the portstartupitem.tcl file for some new startupitems and I want to test it so I tried replacing the current copy in ${prefix} with the modified file but it isn't recognizing my new variables. What is the proper way to test a new portstartupitem.tcl file?
Great idea to work on that stuff a bit more. Modifying the code in $ {prefix} is the right thing to do. I'm not sure which variables you're having trouble with, but one thing to be aware of is that the option variables for startupitem are declared in portdestroot.tcl.
James, You were right, defining the new keywords in portdestroot.tcl made them available. They need some more review and attention but I've got these new keywords working: startupitem.inetdcompat startupitem.inetdcompat.socketsvcname startupitem.inetdcompat.nowait They are attached to this ticket: http://trac.macosforge.org/projects/macports/ticket/11824 How hard do you think it would be to support multiple startupitems? If I'm not mistaken only one is supported now. I have ports that could use more than one startup script. Mark
While we're on the subject of StartupItems/LaunchDaemons, I had a quick question as well: is there any reason startup is always passed through daemondo? I understand that, in some cases, it's the only viable option. However, in others, I know of no reason this is necessary. I've been using launchd directly with lighttpd, mysql5, and ccxstream for some time with no adverse affects; see: http://xml.sfiera.net/net.sfiera.lighttpd.plist http://xml.sfiera.net/net.sfiera.mysql5.plist http://xml.sfiera.net/net.sfiera.ccxstream.plist Is there some way of providing support for this alternate type of startup item to Tiger installations? It's not that important now, though it would be necessary if, for example, lighttpd were ever to support launchd-style port selection. (It's perfectly understandable if the answer is, "we'll think about it when Leopard comes out and we only target launchd") Chris
Hi Chris, On Apr 22, 2007, at 2:17 PM, Chris Pickel wrote:
While we're on the subject of StartupItems/LaunchDaemons, I had a quick question as well: is there any reason startup is always passed through daemondo? I understand that, in some cases, it's the only viable option. However, in others, I know of no reason this is necessary. I've been using launchd directly with lighttpd, mysql5, and ccxstream for some time with no adverse affects; see:
http://xml.sfiera.net/net.sfiera.lighttpd.plist http://xml.sfiera.net/net.sfiera.mysql5.plist http://xml.sfiera.net/net.sfiera.ccxstream.plist
Yes, there are certainly cases where we don't need daemondo in the loop. If the executable option is given, for instance, we know that we can safely use launchd to directly execute the application.
Is there some way of providing support for this alternate type of startup item to Tiger installations? It's not that important now, though it would be necessary if, for example, lighttpd were ever to support launchd-style port selection.
(It's perfectly understandable if the answer is, "we'll think about it when Leopard comes out and we only target launchd")
Yes, when leopard finally roars it will be much easier to extend and enhance the startup items support without also having to worry about keeping the legacy system starter items going. James
Hi Mark, On Apr 22, 2007, at 1:50 PM, markd@macports.org wrote:
James Berry <jberry@macports.org> on Saturday, April 21, 2007 at 7:45 PM -0800 wrote:
I think it would be desirable to have a startupitem that supports inetdcompatibility in MacPorts. It seems to me it wouldn't be that hard since the heavy lifting was already done in MP 1.2. So I've hacked the portstartupitem.tcl file for some new startupitems and I want to test it so I tried replacing the current copy in ${prefix} with the modified file but it isn't recognizing my new variables. What is the proper way to test a new portstartupitem.tcl file?
Great idea to work on that stuff a bit more. Modifying the code in $ {prefix} is the right thing to do. I'm not sure which variables you're having trouble with, but one thing to be aware of is that the option variables for startupitem are declared in portdestroot.tcl.
James,
You were right, defining the new keywords in portdestroot.tcl made them available. They need some more review and attention but I've got these new keywords working:
startupitem.inetdcompat startupitem.inetdcompat.socketsvcname startupitem.inetdcompat.nowait
They are attached to this ticket: http://trac.macosforge.org/projects/macports/ticket/11824
That looks pretty good. I'd love to hear feedback from others, but I'd favor commiting this to allow some experimental usage.
How hard do you think it would be to support multiple startupitems? If I'm not mistaken only one is supported now. I have ports that could use more than one startup script.
I don't think that was really anticipated in the design; we've have to change the syntax somehow to allow multiple items. Jmes
startupitem.inetdcompat startupitem.inetdcompat.socketsvcname startupitem.inetdcompat.nowait
They are attached to this ticket: http://trac.macosforge.org/projects/macports/ticket/11824
That looks pretty good. I'd love to hear feedback from others, but I'd favor commiting this to allow some experimental usage.
I'll need to add something to check whether the values are yes/no or true/false etc. Right now it just checks for the presence of keywords so it isn't fully safe for users. Though it's probably trivial, I've never done Tcl except for Portfile level stuff so I'll see how to do that and add that stuff in a few days and test it a few more times and it could be committed then. I'll do a little more on it and then nag the list about committing it.
How hard do you think it would be to support multiple startupitems? If I'm not mistaken only one is supported now. I have ports that could use more than one startup script.
I don't think that was really anticipated in the design; we've have to change the syntax somehow to allow multiple items.
I suppose it wouldn't be a priority since few ports would use it, I have only one that would and I'm hand coding it for the 2nd startup item. Though I haven't looked at any of the code that parses portfiles, I'm guessing it isn't trivial for an elegant solution. Mark
participants (3)
-
Chris Pickel
-
James Berry
-
markd＠macports.org