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
