Date: Mon, 03 Jun 2002 23:43:08 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Kris Kennaway <kris@obsecurity.org> Cc: Garance A Drosihn <drosih@rpi.edu>, arch@FreeBSD.ORG Subject: Avoiding unnecessary breakage Message-ID: <3CFC617C.849AF2C6@mindspring.com> References: <20020602010108.B16166@espresso.q9media.com> <20020603011903.Y2566-100000@gamplex.bde.org> <20020603162508.A34224@xor.obsecurity.org> <3CFC00A9.BD98B7BD@mindspring.com> <p05111722b921be8398e3@[128.113.24.47]> <3CFC16DD.240E4AFD@mindspring.com> <20020603183726.A38159@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > On Mon, Jun 03, 2002 at 06:24:45PM -0700, Terry Lambert wrote: > > No, you don't need a cluster. > > Um, yes you do. If this is the *only possible way* to tell if a port will be broken by a FreeBSD change, then I hold little hope that your request that people avoid breaking ports with their commits can ever be satisfied. > Um, Terry, we have over 7000 ports now. It takes our 8-way cluster 20 > hours to build them (sorry, the 8 hours I said earlier was wrong); as > already stated it runs at close to 100% capacity the entire time. > Therefore a good estimate of the number of equivalent CPU-hours is > 8*20 hours = 6 2/3 CPU-days. > > Very little time is wasted with the cluster sitting idle waiting for > dependencies to build (and I can probably get that down to 0 time > wasted if I just reorder the makefile a bit to start the build of long > dependency branches like GNOME first - GNOME and KDE are the only > "choke points" where the cluster ends up idling for a few minutes > except for one or two machines: by that time everything else is > finished anyway). Thanks for the real information. I was hoping, from my old understanding of the ports build out from a past discussion with Satoshi Asami, that it was possible to shave a factorial off of the build time because the build-out itself was reponsible for signalling missing package dependencies. This message implies that, even if you installed packages for previous versions of all ports so that all build dependencies bould be satisfied for all ports, without building anything but the port itself (without installing it), it would not significantly reduce the overall build time. I knew that some of the build-out was serialized, but I was hoping the average dependency depth wasn't as shallow as it appears to be. 8-(. If this is all that can be done, it look like quadrupling the number of machines, and making the cluster generally available to attempts builds on "-current + patches" (to get the test time for ports breakages caused by a base OS change to under 5 hours), is probably not a workable solution to the problem. I rather expect that if the resources for this existed, they would already be in use as part of the "ports cluster". Short of going on an "interface usage classification" binge, I don't really see how it would be possible to automate the process of identifying ports that would be broken by a proposed change, other than breaking them, and letting you do the build that finds the breakage, and the notifying the ports maintainers that they need to "take care of it" on a per-individual-port basis. > No, because the above is wrong ;-) > > Please accept that I actually know what I'm talking about (since I've > been managing the ports cluster for about 8 months now) and just drop > the matter. It's ancillary to the matter you raised, about people breaking ports with commits to the base OS. I don't believe in "bit rot", but if, as everyone is claiming, it's impossible to reduce the problem, I think you are going to have to just live with the consequences of base OS changes meaning broken ports which don't show up until you do your builds. Sorry. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CFC617C.849AF2C6>