[MacPorts] #44497: Change port load to use MacPorts plists directly (was: port load issue)

[MacPorts]

#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