Mirror size & completeness of binaries

[Rainer Müller]

On 2018-03-30 21:20, Ryan Schmidt wrote:
> I have not yet heard any reason why we need to change the file structure of the packages server.

The start of the discussion was to have mirrors that only provide a
subset of the packages, for example the latest release. It would be a
lot easier to see what a mirror provides if that was visible through a
top-level directory and it would also make it clear where the mirror
should be listed.

For example, in a future archive_sites.conf:

name       macports
platform   darwin 18
urls       https://packages.macports.org/10.14/ \
           https://foo.bar.packages.macports.org/10.14/

name       macports
platform   darwin 17
urls       https://packages.macports.org/10.13/ \
           https://bar.baz.packages.macports.org/10.13/

... and so on.

With this layout, it would be trivial to spot if one of the mirrors does
not actually provide packages for this version. When just excluding
*darwin_X*, not so easy.

>> PS: if we gradually move packages.macports.org to a different
>> subdomain, we could, say, one year after the move, reuse that
>> subdomain for package index :)
> 
> If by "package index" you mean the one-web-page-per-port system that we've long desired but not yet implemented, then I had always assumed it would be located under www.macports.org/ports; we should stop creating separate hostnames for every new thing and instead try to create a single cohesive web experience.

There has been no major update to the website in the last 10 years.
Whoever is going to create such a ports index should not have the burden
to redesign the rest of the website. Every second link on
www.macports.org is already going to another domain. I am not against
having the same design for all content on the web, but it is a larger
project than just getting such a ports index at all and I would not care
if it did not match any of the others at first.

Rainer