Change port load to use MacPorts plists directly

[ora.et.labora@…]

The manual page of port load states:

   load
     Provides a shortcut to using launchctl to load a port's daemon (as installed in /Library/LaunchDaemons).  It runs:

           launchctl load -w /Library/LaunchDaemons/org.macports.${port}.plist

Is this correct? Cause it does not make much sense having more than one MacPorts installation. Rather, the following should happen (or be documented):

           launchctl load -w $MP_PREFIX/etc/LaunchDaemons/org.macports.${port}.plist 

This way, the "port" command determines MP_PREFIX and starts up the proper daemon.

In addition then, there is also not need to create links in /Library/Launch* (outside of $MP_PREFIX), hence also no need for those two macports.conf properties:

startupitem_type
startupitem_install

Property startupitem_type is not necessary as just always all startup items can (and should) be generated below $MP_PREFIX. The other property - startupitem_install - is not neccessary because not conflicts can be created.

If a user would like to auto start-up a daemon, then he/she would need to create that symlink link herself or a further subcommand of "port" could do the job. In addition, if a port is going to be removed, a symlink check could be run which would warn a user if a dangling symlink would be the result of a port removal.

[larryv (Lawrence Velázquez)]

Replying to ora.et.labora@…:

Is this correct? Cause it does not make much sense having more than one MacPorts installation.

Users commonly maintain special-purpose MacPorts installations for testing and packaging software.

Rather, the following should happen (or be documented):

           launchctl load -w $MP_PREFIX/etc/LaunchDaemons/org.macports.${port}.plist 

This way, the "port" command determines MP_PREFIX and starts up the proper daemon.

But launchd would not be able to automatically start the job at boot/login, which is probably the behavior most users expect.

In addition then, there is also not need to create links in /Library/Launch* (outside of $MP_PREFIX), hence also no need for those two macports.conf properties:

startupitem_type
startupitem_install

Property startupitem_type is not necessary as just always all startup items can (and should) be generated below $MP_PREFIX. The other property - startupitem_install - is not neccessary because not conflicts can be created.

I agree that these overlap, and one should be removed (#36770).

If a user would like to auto start-up a daemon, then he/she would need to create that symlink link herself

Again, most users probably expect this behavior by default, so adding an additional step would be unwelcome busywork.

or a further subcommand of "port" could do the job. In addition, if a port is going to be removed, a symlink check could be run which would warn a user if a dangling symlink would be the result of a port removal.

MacPorts records the files installed by a port during the install process; I don’t think it currently has a way of editing that record after installation.

[ryandesign (Ryan Carsten Schmidt)]

It used to be that OS X would not automatically start daemons unless their plists were in /Library/LaunchDaemons. If that's no longer the case, what version of OS X changed this? If it is still the case, then I don't think we want to change things to make it harder for users to have daemons launched at startup.

[larryv (Lawrence Velázquez)]

​This Apple Developer document, dated 15 July 2014, suggests that that behavior has not changed.

[ora.et.labora@…]

Replying to larryv@…:

Rather, the following should happen (or be documented):

           launchctl load -w $MP_PREFIX/etc/LaunchDaemons/org.macports.${port}.plist 

But launchd would not be able to automatically start the job at boot/login, which is probably the behavior most users expect.

Be aware that this is a different subject! My proposal above would not change the expected behaviour, i.e. if a sym link from /Library/LaunchDaemons into /opt/local/etc/LaunchDaemons is present, then launchd boots that process as usual. With my proposal however, even if I have configured startupitem_install no in macports.conf, I can still do a port load $portname to launch a process. The current behaviour is that (a manua) removal of a symbolic link in /Library/LaunchDaemons renders port load|unload broken.

---

In addition then, there is also not need to create links in /Library/Launch* (outside of $MP_PREFIX)

Perhaps it's best not to continue with this proposal then. I just expect that no software is about to run after having *installed* software. It's just me who want to be in control when I'm going to run software. I would also be very happy if the general rule is that *absolutely nothing* is installed or changed outside of /opt/local (except the installation folder of MacPorts itself).

[larryv (Lawrence Velázquez)]

Replying to ora.et.labora@…:

Be aware that this is a different subject! My proposal above would not change the expected behaviour, i.e. if a sym link from /Library/LaunchDaemons into /opt/local/etc/LaunchDaemons is present, then launchd boots that process as usual.

The expected behavior is that port load loads a job immediately and configures it to load automatically at boot/login. Your proposal would only do the former.

With my proposal however, even if I have configured startupitem_install no in macports.conf, I can still do a `port load $portname` to launch a process.

A new command (e.g., port start) would be more appropriate for this and would not break existing functionality.

The current behaviour is that (a manua) removal of a symbolic link in /Library/LaunchDaemons renders port load|unload broken.

Manual removal of a symlink in /Library/LaunchDaemons also renders the relevant port broken and is entirely unsupported.

I just expect that no software is about to run after having *installed* software. It's just me who want to be in control when I'm going to run software.

Although MacPorts does allow ports to automatically load jobs upon installation, we don’t look favorably on it. I can only think of one that actually does so (certsync); all other ports require an explicit port load.

I would also be very happy if the general rule is that *absolutely nothing* is installed or changed outside of /opt/local (except the installation folder of MacPorts itself).

That’s our general rule, but if implementing useful functionality requires us to install files outside of the MacPorts prefix, we do. Allowing automatic starting of launchd jobs is the only general case I can think of; a specific case is libcxx on older OS X.

On the other hand, I can't think of a case in which MacPorts modifies already-existing files, other than the installer package adding the prefix to the user's .profile.

[jmroot (Joshua Root)]

In ec4ae2dc3d0f736c3c247fcf83e33f87223fad2f/macports-base:

Allow port (un/re)load with startupitem.install=no

This may not result in the item being loaded at boot/login on all OS
versions, but I guess it's better than nothing.

Fixes: #44497