Date: Mon, 03 Jun 2002 16:50:01 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Kris Kennaway <kris@obsecurity.org> Cc: Bruce Evans <bde@zeta.org.au>, Mike Barcroft <mike@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: Removing wait union Message-ID: <3CFC00A9.BD98B7BD@mindspring.com> References: <20020602010108.B16166@espresso.q9media.com> <20020603011903.Y2566-100000@gamplex.bde.org> <20020603162508.A34224@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > On Mon, Jun 03, 2002 at 01:22:14AM +1000, Bruce Evans wrote: > > I think the only potential problem is use of the compatibility cruft > > in deprecware outside the base system. It would be useful to have a > > quick way to determine how many ports a change in a standard header > > affects. > > I'm always happy to test proposed patches on the ports cluster. I think the problem needs something other than the ports cluster. The ports cluster is designed to keep dependencies seperate, so it serializes a lot of things that could otherwise be done in parallel, to ensure dependency order is maintained. I think that, for the most part, what you care about in this case is not catching broken dependencies, but catching breakage caused by system cahnges, not inter-port dependency changes. This really argues that you could install the ports sources on a machine, and then build out all of the ports from local copies of all the packages, in parallel -- if you had already installed the things on which they dependend on the machine. This would let you basically re-build in parallel, without needing to enforce ports dependency order, on a single machine instead of a cluster, and much faster, because all the dependencies would already be there (from the previous "install" of all ports, rather than from the build process for an individual port). All the builds could be done in parallel in their own subdirectories (not installed), so the process could be much fater than using the cluster the way the cluser is supposed to be used. -- 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?3CFC00A9.BD98B7BD>