Kris Kennaway wrote:

You need to keep statistics of how many times each individual port is built, in the cluster case (i.e. you need a combinatoric dependency map and a way to factor out permutations that are necessary for solving the ports problem, but not necessary for solving the "what breaks?" problem).

When you build a given port on its own little virtual box, you also build all the ports on which it depends. This is by design, since it avoid the problem of finding dependencies which are not explicitly called out.

In the case of a system change, you aren't concerned about that; in fact, you *want* it to happen, since it reduces the total build time.

How many machines are in the ports cluster? Knowing how many total cycles are required, and how many redundant dependency builds happen, would be a good way to ballpark whether it's feasible to build a single machine that can tell what is broken by a proposed base OS change, before the change is checked in.

-- Terry

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message