Preparing for 2.6.0 beta

[Ryan Schmidt]

On Sep 19, 2019, at 21:22, Mojca Miklavec wrote:

> On Fri, 20 Sep 2019 at 03:38, Ryan Schmidt wrote:
>> 
>> 
>> 
>> On Aug 24, 2019, at 23:20, Joshua Root wrote:
>> 
>>> On 2019-8-25 03:00 , Mojca Miklavec wrote:
>>>> Would it be possible to set up at least one builder with 10.6 running
>>>> MacPorts master, building all ports with libc++ (apparently default by
>>>> now in master), just not uploading the archives to the public site, or
>>>> potentially uploading them to a 10.6 subfolder? That is, instead of
>>>> putting the file under
>>>>   http://packages.macports.org/clang-3.4/clang-3.4-3.4.2_12.darwin_10.x86_64.tbz2
>>>> we would put it under
>>>>   http://packages.macports.org/10.6/clang-3.4/clang-3.4-3.4.2_12.darwin_10.x86_64.tbz2
>>>> or something else than 10.6 (darwin10.x86_64, 10.6.x86_64, ...).
>>>> 
>>>> That way we could at least have all the packages ready by the time
>>>> when we do the switch.
>>> 
>>> I guess that depends on how much time Ryan has to work on this.
>> 
>> In my opinion, it would have been a good idea to develop a plan for having the archives for libc++ on older systems at different URLs (either subdirectories or different archive filenames). That way, we could have deployed new builders to build the libc++ archives for older systems prior to the release, so that they would be available at release.
>> 
>> However, since Joshua decided to flip the switch for libc++ on older systems without such a plan being in place, we won't have archives for libc++ on older systems available at release of 2.6.0, and users will just have to wait for the builds to finish or build things themselves.
> 
> I would certainly not back out from the changes.
> But if you Ryan have time to set up at least one virtual builder for
> 10.6 running the RC (ideally three, but one would already make a huge
> difference), the files could be placed to a different location
> immediately from the buildbot server, and we could at least give it a
> bit of a headstart as I expect various troubles.
> 
> I guess the release could wait for a small number of days, and during
> that time we could still get quite some important ports built, and fix
> some major issues that will pop up in any case, and it's better to fix
> them sooner than later.
> 
> If this could be done quickly, we could still add something like "if
> OS X < 10.9 and x86_64, then fetch binaries from a different location"
> to the macports base.

The problem with this suggestion is that it would rebuild all ports, even those that don't use C++. That would take a lot of time.


> Out of curiosity: since the binaries will have to change, but names
> won't - how will our buildbot setup even behave? I expect that for the
> start, unless we delete all the existing 10.6 packages from the
> server, many packages won't even be rebuilt if we "force build" them,
> since the file will be found on the server. And even if it will get
> rebuilt: will it be replaced on the server with the new one?

We will delete all old C++-using archives for 10.6-10.8 before updating the buildbot workers to 2.6.0. Josh has provided me with a script to do that.


> I also expect quite some performance issues because the full compiler
> chain will need to be deactivated for every single trivial port, but
> that's not as critical (as long as we don't run into bootstrapping
> issues for each cycle).

Yes that's not great. But it already happens for any port using the cxx11 1.1 portgroup, right?