[MacPorts] #41540: fetch-crl @3.0.12: new submission

Tue Nov 26 15:29:45 PST 2013

#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