Mirorring distfiles

[Joshua Root]

On 2018-3-2 09:09 , Mojca Miklavec wrote:
> On 22 February 2018 at 21:14, Ryan Schmidt wrote:
>> On Feb 22, 2018, at 04:57, Mojca Miklavec wrote:
>>
>>> Dear Ryan,
>>>
>>> What is the current situaton with mirorring distfiles
>>
>> Unchanged. I need to create a buildworker on the buildmaster. I then need to deploy the buildbot configuration that does the mirroring, figure out what configuration it needs if any, and see if it works, and if not, how it needs to be fixed.
> 
> So does that mean that the code is there and merely needs testing? Or
> do you also need to write the code.

Much of the code exists, but a bit more is needed. The script needs to
filter out ports that have 'nomirror' in their licenses, and it needs to
get a ports tree.

Last I remember I was waiting for details of where the files should go,
and asked whether it would make sense to simply fold mprsyncup into the
mirroring job, rather than maintaining yet another ports tree or
synchronising two users of the same one.

(This discussion was on macports-infra back in September BTW.)

>> You're talking about choosing how to differentiate the libc++ binaries from the libstdc++ binaries?
> 
> Yes. I still find it super painful that we did not manage to migrate
> to libc++ over all those years due to a basically "trivial" issue.
> 
> My suggestion would be to use one hacking session during the meeting
> to implement a few lines of code that take care of renaming the
> binaries + test whether users could switch to libc++ using migration
> tool written by Umesh.

IMO the way forward is to just say libc++ is the new normal on all
platforms where it can work. For this we need a few things:

Fields in the registry indicating whether each port links with a C++
runtime and which one, and whether the port explicitly chose it or went
with the default. The former can be filled in by rev-upgrade when it
scans for broken linking.

Rev-upgrade then also needs to check whether c++ ports that didn't
explicitly choose a runtime are using the current default, and treat
them as broken if not.

Then we can release a new base version that defaults to libc++ on the
affected platforms, and at the same time delete the archives for those
platforms of all c++ ports from the packages server.

None of this is particularly hard, and will minimise disruption and
rebuilding. I'm sure you should be able to implement all the code in the
hacking session. :)

- Josh