On 10 August 2016 at 10:37, Ryan Schmidt wrote: > > Currently, there is only one PortIndex file generated on the server, and > published to the rsync server, for each OS name/version/endianness > combination. So for example, there is one PortIndex for Darwin 12 Intel. > There is not currently a separate PortIndex for Darwin 12 Intel with libc++, > so anyone with e.g. OS X 10.8 with libc++ syncing from the rsync server will > see the version of this port as 3.20.2 not 3.18.3 when querying the index, > for example when running port info or port outdated. If we're going to change > Portfile attributes such as version that get stored in the index based on the > C++ library, and I agree this is a situation that would arise more and more > as newer versions of software require libc++, should we make a separate > libc++ PortIndex for 10.6/10.7/10.8? > > > We also still need to decide how to differentiate the URLs for libc++ > packages from the URLs of the existing libstdc++ packages. One suggestion was > to add cxx_stdlib as a variable in archive_sites.conf, and upload the libc++ > archives with the same names as the libstdc++ archives but in a new > subdirectory, e.g. https://packages.macports.org/libc++/.
Some time back I opened a ticket at https://trac.macports.org/ticket/50448 During the MacPorts meeting the suggestion was to start using a different path/prefix, to add an additional variable to the database (and certainly not to mix this with changes of the compression format). We could brainstorm (or at least summarize the discussion happinging on the mailing list) in that ticket. > Once we decide that, then do we adopt the same strategy for naming and > placing the PortIndex files? (I admit that I wasn't even aware that this could also be a problem for PortIndex.) Mojca _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev