#44497: Change port load to use MacPorts plists directly ------------------------------+-------------------------------- Reporter: ora.et.labora@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.1 Resolution: | Keywords: Port: | ------------------------------+-------------------------------- Changes (by larryv@…): * owner: markd@… => macports-tickets@… * component: guide => base Comment: Replying to [ticket:44497 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. -- Ticket URL: <https://trac.macports.org/ticket/44497#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X

#44497: Change port load to use MacPorts plists directly ------------------------------+-------------------------------- Reporter: ora.et.labora@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.1 Resolution: | Keywords: Port: | ------------------------------+-------------------------------- Comment (by larryv@…): [https://developer.apple.com/library/mac/documentation/macosx/conceptual/bpsy... This document], dated 15 July 2014, suggests that that behavior has not changed. -- Ticket URL: <https://trac.macports.org/ticket/44497#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X

#44497: Change port load to use MacPorts plists directly ------------------------------+-------------------------------- Reporter: ora.et.labora@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.1 Resolution: | Keywords: Port: | ------------------------------+-------------------------------- Comment (by larryv@…): Replying to [comment:4 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. 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`. -- Ticket URL: <https://trac.macports.org/ticket/44497#comment:5> MacPorts <http://www.macports.org/> Ports system for OS X