On Oct 25, 2018, at 14:52, Richard L. Hamilton wrote:
> Took me a moment to realize you were referring to the Portfile facility, not
> the obsoleted (as of what OS version?) OS facility, regarding StartupItems.
Yes, I'm referring to the MacPorts portfile options whose names begin with
"startupitem".
https://guide.macports.org/#reference.startupitems
These options were designed and added to MacPorts back when macOS used
StartupItems and launchd did not exist yet.
> Still, I see the plist file you describe is notably simpler than something
> that the Portfile startupitems facility would have generated (i.e. the one
> MacPorts installed); no daemondo, no wrapper script.
Yes, that is correct; those were not needed for rsync. For the daemons I run on
the buildbot/rsync server, I decided to write my own launchd plists, rather
than rely on any the port might have provided, for several reasons. In some
cases I wanted to make changes to the launchd plist that MacPorts doesn't have
options for. For example for rsync I wanted to do on-demand launching. For
mprsyncup and backups, I wanted a task that runs at a recurring interval. In
other cases, such as the buildbot workers, I needed multiple launchd plists per
port, a feature MacPorts now has but did not have when I set up this
infrastructure. And finally, I wanted to be in control of what runs on my
server. I did not want to risk some other developer making a change to a port's
launchd plist that I did not want.
> AFAIK, launchd was introduced with OSX Tiger (10.4);
That's right. When Tiger was introduced, code was added to the MacPorts
startupitem options to generate either StartupItems or launchd plists depending
on the system version and/or the value of a macports.conf setting.
> does MacPorts still support anything older than that?
No, that's the oldest version MacPorts runs on. For that reason, support for
generating StartupItems was removed from MacPorts a little while ago; the
startupitem options are now exclusively for generating launchd plists.
> If not, then why not supply launchd plists directly when their functionality
> would be sufficient?
We've had this debate many times before on the mailing list. My recollection is
that sometimes it is not sufficient; sometimes daemondo is needed. I don't
remember all of the conditions under which it is needed. I think at least one
reason had to do with daemons that were not written with launchd in mind, and
which were designed to always fork themselves into the background; daemons used
with launchd must *not* do that, otherwise launchd will think the program
crashed and will relaunch it over and over. Daemondo accommodates daemons that
do not offer the option not to fork.
We would need a new startupitem option for the portfile author to specify
whether daemondo should be used for a particular plist or not. I'm not aware of
anybody starting any work on that yet.
> And couldn't that be done (when sufficient) directly rather than using the
> Portfile startupitem functionality?
You mean: couldn't a portfile author write a launchd plist manually, put it in
the files directory, and write code in the post-destroot block to copy it to
the right place? Yes, a portfile author could do that; many already have. It
seems cumbersome to me, especially since those plists usually need to contain
some variables from the portfile environment, such as the prefix. I think we
think it's simpler for the portfile author to specify a few Tcl options in the
portfile rather than have to write a plist and copy it and reinplace it. But I
don't know. Maybe we should just be making launchd plists directly these days.
Maybe creating a whole set of MacPorts options around every launchd plist
feature is overkill and ultimately more confusing. Part of the reason why we
have those options was portability to multiple implementations (StartupItems
and launchd and whatever other OSes use), but these days there is only the
launchd implementation.
MacPorts does have commands that wrap "sudo launchctl load -w" and "sudo
launchctl unload -w" (namely "sudo port load" and "sudo port unload"); some
care would have to be taken by the portfile author to ensure that the launchd
plist name and location matches what MacPorts expects in order to preserve that
functionality.
