#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