#41540: fetch-crl @3.0.12: new submission ------------------------------+-------------------------------- Reporter: Peter.Danecek@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: fetch-crl | ------------------------------+-------------------------------- Comment (by ryandesign@…): Replying to [comment:7 Peter.Danecek@…]:
I renamed the plist file comply with the Macports naming scheme, but I realise it is not always followed by other ports. {{{ lrwxr-xr-x 1 root couchdb 57 Sep 4 18:01 org.apache.couchdb.plist -> /opt/local/Library/LaunchDaemons/org.apache.couchdb.plist lrwxr-xr-x 1 root admin 63 Nov 23 21:45 org.freedesktop.avahi- daemon.plist -> /opt/local/etc/LaunchDaemons/org.freedesktop.avahi- daemon.plist lrwxr-xr-x 1 root admin 65 Nov 23 21:45 org.freedesktop.avahi- dnsconfd.plist -> /opt/local/etc/LaunchDaemons/org.freedesktop.avahi- dnsconfd.plist lrwxr-xr-x 1 root admin 66 Jul 4 16:58 org.freedesktop.dbus- system.plist -> /opt/local/Library/LaunchDaemons/org.freedesktop.dbus- system.plist lrwxr-xr-x 1 root admin 82 Aug 14 22:11 org.macports.VirtualBox.plist -> /opt/local/etc/LaunchDaemons/org.macports.VirtualBox/org.macports.VirtualBox.plist lrwxr-xr-x 1 root admin 76 Nov 12 17:06 org.macports.antinat.plist -> /opt/local/etc/LaunchDaemons/org.macports.antinat/org.macports.antinat.plist lrwxr-xr-x 1 root admin 76 Nov 20 19:12 org.macports.apache2.plist -> /opt/local/etc/LaunchDaemons/org.macports.apache2/org.macports.apache2.plist lrwxr-xr-x 1 root admin 80 Mar 23 2013 org.macports.cassandra.plist -> /opt/local/etc/LaunchDaemons/org.macports.cassandra/org.macports.cassandra.plist lrwxr-xr-x 1 root admin 76 Nov 7 13:06 org.macports.mongodb.plist -> /opt/local/etc/LaunchDaemons/org.macports.mongodb/org.macports.mongodb.plist -rw-r--r-- 1 root admin 645 Sep 19 18:35 org.macports.privileged_startx.plist lrwxr-xr-x 1 root admin 74 Nov 18 2012 org.macports.rsyncd.plist -> /opt/local/etc/LaunchDaemons/org.macports.rsyncd/org.macports.rsyncd.plist }}}
And this has been a problem, for example you'll find many tickets (e.g. #34359) and mailing list discussions from people encountering errors on activation of dbus, because its plist has a nonstandard name. Launchd plists have to be installed in (or symlinked into) the public directory /Library/LaunchDaemons, so if a user wants to [http://guide.macports.org/chunked/installing.macports.uninstalling.html uninstall MacPorts] but the `port` command is not working and he has to resort to using `sudo rm -rf`, the best we can do is give them a list of globs patterns to delete, and since /Library/LaunchDaemons may contain non-MacPorts files, we can't tell them to delete everything there; we can only tell them to delete everything starting with org.macports, which doesn't cover ports like dbus that install plists with different prefixes, so the dbus files remain. Then the user reinstalls MacPorts and encounters errors activating dbus. So if you're installing a launchd plist with MacPorts, please if possible use the org.macports prefix.
So what is the background here, and why `org.macports.privileged_startx.plist` installed directly?
I suppose because the xinit port is a little unusual. You could ask that port's maintainer why it's done that way. It may be a bug. It may be part of the cause for [https://lists.macosforge.org/pipermail/macports- users/2013-November/034019.html this problem]. Best would be to do what MacPorts base does: install in ${prefix}/etc/LaunchDaemons, then, if requested, symlink to the real location.
Another doubt is about these subdirectories in `/opt/local/etc/LaunchDaemons`:
{{{ petr% ls -la total 8 drwxr-xr-x 10 root admin 340 Nov 26 15:36 . drwxr-xr-x 51 root admin 1734 Nov 26 15:36 .. -rwxr-xr-x 1 root admin 453 Nov 23 21:45 org.freedesktop.avahi- daemon.plist -rwxr-xr-x 1 root admin 457 Nov 23 21:45 org.freedesktop.avahi- dnsconfd.plist drwxr-xr-x 4 root wheel 136 Aug 14 22:11 org.macports.VirtualBox drwxr-xr-x 3 root wheel 102 Nov 12 17:06 org.macports.antinat drwxr-xr-x 4 root wheel 136 Nov 22 22:32 org.macports.apache2 drwxr-xr-x 3 root wheel 102 Nov 7 12:13 org.macports.cassandra drwxr-xr-x 3 root wheel 102 Nov 7 13:07 org.macports.mongodb drwxr-xr-x 4 root wheel 136 Oct 23 17:31 org.macports.rsyncd }}}
I would have installed directly in `/opt/local/etc/LaunchDaemons`. Is there anything wrong about this?
It looks like MacPorts base creates directories when the port specifies `startupitem.start`, `startupitem.stop`, and/or `startupitem.restart`, because in those cases it needs to write a short wrapper shell script containing those commands and references that script from the plist, and I guess it seemed neater to have only a single item in ${prefix}/etc/LaunchDaemons for each port. When using `startupitem.executable` instead, which is the preferred method, then the plist can reference that executable directly and doesn't need a wrapper script.
The guide does not mention `sudo port load ` and `sudo port unload`, but from `port(1)` I would understand that it translates to the corresponding `launchctl` commands. But the line {{{ system "launchctl remove org.eugridpma.fetch-crl || true" }}} has no correspondence. Is it save to just leave this line away? Is there some more magic involved with `port load / unload`?
There's no magic; `port load` and `port unload` map directly to `launchctl`; e.g. browser:trunk/base/src/port1.0/portload.tcl. From this we can also see that the path you should be symlinking the plist to is /Library/${startupitem.location}/${startupitem.plist}. I don't know what `launchctl remove` does.
Might it be possible and/or reasonable to use `startupitem.create yes` instead and add the `StartInterval` in a later stage? Is there some hook, e.g. something like `startupitem-append` to do this? Or at which stage this could be done?
There's no hook specifically for that. This is what I meant when I said above that MacPorts doesn't give you a lot of control over it. I don't know exactly when the plist is created; you could try patching it in post- destroot if you want to go that route. -- Ticket URL: <https://trac.macports.org/ticket/41540#comment:9> MacPorts <http://www.macports.org/> Ports system for OS X