On 2018-04-09 00:06, Joshua Root wrote:
> On 2018-4-9 07:55 , Rainer Müller wrote:
>> On 2018-04-08 03:26, Joshua Root wrote:
>>> Joshua Root (jmroot) pushed a commit to branch master
>>> in repository macports-base.
>>> https://github.com/macports/macports-base/commit/3dde77d7d6c66dbb8fcc1d4b1b4972a2ac8b1947
>>> The following commit(s) were added to refs/heads/master by this push:
>>> new 3dde77d Honour startupitem.install at activation time 3dde77d is 
>>> described below
>>> commit 3dde77d7d6c66dbb8fcc1d4b1b4972a2ac8b1947 Author: Joshua Root 
>>> <j...@macports.org>
>>> AuthorDate: Sun Apr 8 11:16:22 2018 +1000
>>> Honour startupitem.install at activation time When activating files,
>>> move plists from /Library/Launch* to ${prefix}/etc/Launch* if the port
>>> was built with startupitem_install on but it is currently off, and
>>> vice versa in the opposite case.
>> Somehow this seems complicated. Wouldn't it be simpler to always ship
>> the .plists in ${prefix}/etc/Launch* and only add symlinks in
>> /Library/Launch* on activation if startupitem_install allows it?
> Not that much simpler, strangely enough.

Maybe not in the implementation, but simpler for me to grasp what's
going on. :-)

>> But I guess you did it this way to be compatible with older archives?
> Indeed. It doesn't matter how startupitem.install was set when the
> archives were built, this will DTRT either way.

This handles ports that create .plist files via startupitem.* or the new
startupitems. However, there are also ports that install custom .plist
file to ${destroot}/Library/Launch*. Some ports even do that

Maybe we could rename all *.plist files in these directories to avoid
recreating this logic in many ports? If we handled this automatically at
activation time, ports would no longer have to deal with
${startupitem.install} at all.


Reply via email to