[MacPorts] #65721: app portgroup: callback not used, causing issues when combined with other pgs

[MacPorts]

#65721: app portgroup: callback not used, causing issues when combined with other
pgs
----------------------+-----------------------
  Reporter:  mascguy  |      Owner:  mascguy
      Type:  defect   |     Status:  assigned
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:  2.7.2
Resolution:           |   Keywords:  portgroup
      Port:  gramps   |
----------------------+-----------------------

Comment (by ryandesign):

 Replying to [comment:3 mascguy]:
 > Replying to [comment:2 jmroot]:
 > > There is never any guarantee what order multiple pre- or post- phase
 blocks will run in, so anything that relies on them running in a
 particular order is broken.
 >
 > Hmmm, I thought that `post-destroot` blocks are run in a deterministic
 manner, based on the order in which they're registered.

 As far as I have been able to tell by observation, they run in the order
 registered. I'm not aware of any reason why we should change that behavior
 in base; changing that would just break ports that rely on a particular
 order. Although it is probably best for ports not to rely on the order,
 some ports probably do.

 > Replying to [comment:2 jmroot]:
 > > If gramps needs something to be done before some post-destroot block
 runs, it needs to do it somewhere that runs earlier like destroot or pre-
 destroot.

 It's not gramps that need it. The app portgroup contains a sanity check
 that verifies that the executable you've specified exists. If the gramps
 portfile had created the executable there would be no problem, but in this
 case the executable is a symlink that is created by the python portgroup.
 The app portgroup's sanity check cannot be moved any earlier than post-
 destroot because it checks things that the port should create at destroot
 time, and the python portgroup's symlink creation code cannot be moved any
 earlier than post-destroot because it creates symlinks to every binary
 that was created by the port at destroot time.

 The problem occurs because the app portgroup's post-destroot block is
 registered the moment the app portgroup is included, while the python
 portgroup's post-destroot block is registered the moment python.versions
 is set. Therefore, since portgroups are typically included up top and
 python.versions isn't typically set until later, the app portgroup's post-
 destroot block runs before the python portgroup's post-destroot block.

 I suggested that the solution to this issue is to have the gramps portfile
 tell the app portgroup the location of the real executable that already
 exists, not the location of the symlink to it that the python portgroup
 eventually creates.

 I don't think changing the order in which the app portgroup's post-
 destroot block runs is a good idea at such a late time (so long after the
 app portgroup was created and deployed). All of the ports that already use
 the app portgroup work with the way the portgroup is currently designed.
 Changing it now (e.g. by using an end-of-portfile callback that registers
 the post-destroot at a different time) has the potential to break existing
 ports.

-- 
Ticket URL: <https://trac.macports.org/ticket/65721#comment:7>
MacPorts <https://www.macports.org/>
Ports system for macOS