Rebuilding all ports for MacPorts 2.2

[Joshua Root]

On 2013-3-26 14:23 , Ryan Schmidt wrote:
> Several changes have been made in MacPorts base trunk that affect how most* ports build:
> 
> * library overlinking fixed: https://trac.macports.org/ticket/38010

Only a problem from an end user perspective when ports are overlinked to
a lib whose ABI changes. The overlinking only happens when libtool is
used, and only gets really bad in a few cases like the gnome stack.

> * library header padding maximized: https://trac.macports.org/ticket/29838

Only matters for a tiny minority of users.

> * default optimization level improved: https://trac.macports.org/ticket/38218

Unlikely to make any noticeable difference in most cases.

> Before MacPorts 2.2 is released, we should decide how we want to make these improvements available to users.
> 
> It has been suggested that at minimum we should rebuild all binary packages on the buildbots after they are upgraded to MacPorts 2.2. This would also be good because most of the Lion packages were built with Xcode 4.3.3 and have not been rebuilt since the Lion buildbot was updated to Xcode 4.6.1. Previously, when we've launched new buildbots, they took over a week to build all ports. If we delete all binaries on the packages server and start rebuilding them, there will be more than a week during which MacPorts users will have no access to binaries.

Please, no. This is pointless for the vast majority of ports. If
specific ports don't work correctly when built with older Xcode
versions, rebuilding the binaries does nothing for everyone who already
has them installed anyway.

> We can then either do nothing further, and just allow users to receive these improvements as they rebuild or upgrade ports, or we can proactively force all users to reinstall or rebuild all ports. The library overlinking issue in particular has a ripple effect that's best cured by uninstalling and reinstalling all ports.

Let the changes come in as ports are updated normally. If anything
really needs a rebuild, rev bump it.

> We could introduce the concept of an "era", a MacPorts-global integer that would complement the port-specific epoch, version and revision to tell MacPorts when to consider a port outdated. The era for MacPorts 2.1.x and earlier would be assumed to be 0, and for MacPorts 2.2 it can be increased to 1. Users won't upgrade to MacPorts 2.2 all at the same time, so such a mechanism would ensure that they receive the benefits of these improvements, no matter how long they wait before upgrading to 2.2. The era would be added to archive names if not zero. So e.g. "zlib-1.2.7_0.darwin_12.x86_64.tbz2" would become "zlib-1_1.2.7_0.darwin_12.x86_64.tbz2". This would allow the buildbots to get to work building new "era 1" binaries while leaving the old "era 0" binaries on the server for awhile for users who have not upgraded yet. We could finalize and tag MacPorts 2.2 and install it on the buildbots a week before we release it to users to get all the binaries rebuilt and ready on time.

This is even worse. Speaking as a user, I do *not* want to be forced to
reinstall all my ports for no noticeable benefit. It's just a huge waste
of time, energy and bandwidth.

- Josh