[MacPorts] #55471: Use separate portindexes for libc++ on older systems

[MacPorts]

#55471: Use separate portindexes for libc++ on older systems
--------------------------+----------------------------
  Reporter:  ryandesign   |      Owner:  neverpanic
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.5.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by ryandesign):

 Replying to [comment:26 raimue]:
 > Side note: I do not understand why you would want to hardcode the
 default cxx_stdlib at this place. I would just always add
 `${platindex_cxxlib}` to the remote filename, isn't this much simpler?
 Wasn't your plan to eventually change the default on older systems at some
 point? Hardcoding default values seems to work against that.

 My intention was to not change the remote Portindex filename for current
 users, so that existing MacPorts 2.4.x installations would not break.

 I think when I made this ticket, there had not yet been an initiative to
 change the default value of cxx_stdlib for 10.6-10.8, so I did not
 consider that that might be how we ultimately implement the migration and
 that it might affect these Portindex filenames.

 We could go all out: put the cxx_stdlib into every Portindex filename as
 you suggest, to be used by future versions of MacPorts, and also hardlink
 the old Portindex name without cxx_stdlib to what MacPorts 2.4.x expects.

 > I also have reservations because of users that already have a non-
 default setting for `cxx_stdlib`. With this change, mportsync would expect
 a remote filename that does not yet exist. What are the consequences of
 this? Is the plan to deploy the changes to mprsyncup immediately after the
 2.5.0 release without ever testing the changes against rsync? Will
 mportsync fail gracefully or hard without a remote PortIndex file? Will
 base fall back to generate a PortIndex locally in this case? I see no
 reports of tests or consideration of it in this ticket.

 I did not test it but when I made these patches I assumed MacPorts would
 explode if the remote Portindex does not exist, which is why I created all
 three patches at once in this ticket and expected the changes to mprsyncup
 and portindex to be deployed immediately to the server, so that the
 Portindexes with the new names would be generated and ready to go before
 users would update to a new version of MacPorts that would use them. I'm
 happy to manually patch the copy of portindex that mprsyncup uses on the
 server.

 > The changes to `macports.tcl` require the changes to `mprsyncup`, but
 that requires the changes to `portindex`.
 >
 > I can only review the change to portindex as ready-to-go. The new
 portindex would already fix the problem that PortIndex was generated with
 the wrong value of cxx_stdlib in mprsyncup for legacy platforms. This
 seemed to be the most important fix of this pull request to go into a
 release.

 I just want to make clear again that deploying only this part will ''fix''
 the portindex for ≤ 10.8 with libstdc++ but ''break'' the portindex for
 any users of ≤ 10.8 [wiki:LibcxxOnOlderSystems already using libc++]. I'm
 ok with that, because it will help more users than it harms, and the
 breakage is so minor (a handful of ports not being properly displayed in
 `port outdated`) that I'm only aware of one ≤ 10.8 libstdc++ user
 reporting the problem so far. But I want to make sure we're all clear
 about what will happen if we make this change.

 > I also thought this is what we discussed to do for MacPorts 2.5.0 in our
 online meeting.

 We did discuss it, but I, like Mojca, wasn't entirely clear on why the
 three parts of the fix were to be separated from one another. One reason
 could be if we have not yet agreed that my proposed Portindex filenames
 are the ones we want to use, since after we release a version of MacPorts
 that uses them, we don't want to change them again.

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