[MacPorts] #50448: Change filenames of binary packages built against libc++ on < 10.9

[MacPorts]

#50448: Change filenames of binary packages built against libc++ on < 10.9
--------------------------+--------------------------------
  Reporter:  mojca        |      Owner:  macports-tickets@…
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  base         |    Version:  2.3.4
Resolution:               |   Keywords:
      Port:               |
--------------------------+--------------------------------

Comment (by mojca):

 I have absolutely no experience about hfs, so I cannot comment on that.

 Please also note that I opened this ticket before we had the MacPorts
 meeting. At the meeting we proposed the following solution:
 * Don't bother about the situation with `noarch`, about whether the port
 requires C++ runtime at all and whether the port can be built against
 `libstdc++` at all (C++11 ports cannot and some already switch to `libc++`
 even under default settings): getting it right is way too complex to
 handle in any easy way. (My personal addition: Debian splits all of their
 packages into `arch` part and the generic part and then ships files of the
 generic part just once. We could probably even do that for most of the
 ports and ship generic parts for all OSes, all architectures and both
 configurations (`libc++` vs. `libstdc++`), but then we always have a
 zillion exceptions where one port version doesn't build on the older OS
 and another version doesn't build on a newer OS, so this would inevitably
 cause all kinds of problems anyway.)
 * My personal suggestion was to switch to `.tar.xz` and ship `.tar.xz` for
 `libc++` (on < 10.9) and keep distributing `.tar.bz2` for existing default
 setups (and later gradually switch everything else to `.tar.xz` as well).
 Then we would have no name clashes at all. But most other devs didn't like
 this idea at all, saying that we should not mix the extension/compression
 format with the rest.
 * We proposed to put new binaries under a new prefix. That is, put
 binaries to:
    {{{
    http://packages.macports.org/10.5/ppc
    http://packages.macports.org/10.5/i386
    http://packages.macports.org/10.6/i386/
    http://packages.macports.org/10.6/x86_64/
    http://packages.macports.org/10.7/x86_64/
    http://packages.macports.org/10.8/x86_64/
    }}}
    or perhaps `darwin9` to `darwin12` (rather than OS version numbers),
 architecture is also not required.

 The (most likely) reason why this hasn't been implemented yet is because
 we currently have absolutely no overview/summary of successful and failed
 jobs on the buildbot. At the moment you can look at
 `http://packages.macports.org/<packagename>` and check quickly whether a
 particular port is missing on a particular OS version without having to
 implement the new (but sorely missing) functionality.

 We argued that the lack of functionality on our website shouldn't be the
 reason for keeping the "poor man's method" around and denying support to
 users of old OSes.

 Surely there are other problems. This still doesn't provide any means to
 support installations with non-default prefixes, it doesn't tell anything
 about other user settings etc.

 PS: and of course 10.5 PPC comes with its own set of problems, starting
 with the fact that clang doesn't work properly there, so there are now
 "movements" to allow building C++11 software by setting `gcc6` (or
 earlier) as the default compiler, complicating things even further.

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