Mirror size & completeness of binaries

[Mojca Miklavec]

On 28 March 2018 at 13:58, Rainer Müller wrote:
> On 2018-03-27 13:56, Mojca Miklavec wrote:
>> I don't know about the best way to do it, but I would like to suggest to
>> provide macports mirorring in two different sizes: a small one and a
>> complete one.
>>
>> While I'm a heavy supporter of providing support for legacy systems, I
>> see no reason to mirror files for them on all of our mirrors and cause
>> troubles to them. I would suggest to mirror by default just the latest
>> version of any given source and binary and only support the latest three
>> OSes there. Then we could have additional files to support older systems
>> on a smaller set of mirrors, just on those where it would not cause any
>> additional troubles to them. Since the number of users of legacy systems
>> is much smaller, this should not have a heavy impact on bandwidth to
>> that smaller number of mirrors either.
>>
>> I'm not saying this should be implemented immediately, but I would
>> certainly start thinking about that before we add additional four
>> mirrors (three legacy ones and 10.14).
>
> It would probably help if we had a top-level directory for the macOS
> version. Mirroring a specific subset of the archives would then be trivial.

That would be my point exactly.

For the last meeting I brought a full macports mirror with me. I
initially wanted to mirror just packages for two or three OSes that
participants would brought with them, but it turned out to be
non-trivial (I played with include/exclude rules, then gave up and
simply mirrored everything).

> I know it is nice to see all packages for a port in one place and it is
> easier to check what has already been built. But hopefully we would have
> this information on individual port index pages soon.

Indeed. I don't know about the proper way to do the transition, but
maybe we could implement something in version 2.5.0? That would also
greatly simplify adding the libc++ packages and I'm pretty sure that
we can set something up to have a clear overview about the build
process until the switch to 2.5.0.

Users who don't upgrade to 2.5.0 immediately would have to build from
source for a while, but that's just about the biggest "problem" I can
think of.

Mojca