#44497 closed enhancement (fixed)
Change port load to use MacPorts plists directly
Reported by: | ora.et.labora@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | MacPorts 2.5.0 |
Component: | base | Version: | 2.3.1 |
Keywords: | Cc: | ||
Port: |
Description
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.
Change History (7)
comment:1 follow-up: 4 Changed 10 years ago by larryv (Lawrence Velázquez)
Component: | guide → base |
---|---|
Owner: | changed from markd@… to macports-tickets@… |
Summary: | port load issue → Change port load to use MacPorts plists directly |
comment:2 follow-up: 3 Changed 10 years ago by 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.
comment:3 Changed 10 years ago by larryv (Lawrence Velázquez)
This Apple Developer document, dated 15 July 2014, suggests that that behavior has not changed.
comment:4 follow-up: 5 Changed 10 years ago by ora.et.labora@…
Replying to larryv@…:
Rather, the following should happen (or be documented):
launchctl load -w $MP_PREFIX/etc/LaunchDaemons/org.macports.${port}.plistBut 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).
comment:5 Changed 10 years ago by 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.
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
.
comment:6 Changed 7 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:7 Changed 7 years ago by jmroot (Joshua Root)
Milestone: | → MacPorts 2.5.0 |
---|
Replying to ora.et.labora@…:
Users commonly maintain special-purpose MacPorts installations for testing and packaging software.
But launchd would not be able to automatically start the job at boot/login, which is probably the behavior most users expect.
I agree that these overlap, and one should be removed (#36770).
Again, most users probably expect this behavior by default, so adding an additional step would be unwelcome busywork.
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.