Doug Barton wrote: > > o Leave the ports framework as it is, and implement support for > > parallel building in add-on tool, eg., portupgrade. The tool would > > support automatic parallelism ("portupgrade -a" would automatically > > build ports in parallel where possible), or having several > > user-created instances running at the same time. I'll call this > > "tool-based macro-parallelism". > > I specifically designed portmaster to be able to do this. Separate instances > do not share > anything in common, other than the ports tree and package database. Assuming > that you were > updating two (or more) ports that you were positive did not share any > dependencies in common, > you could run as many portmaster instances as you wanted to, and not have any > problems. > > Where this gets really sticky is in (for example) the -a case. If you run > 'portmaster -l' on > a typical system, you'll see that there are some root ports (no dependencies, > not depended > on), some leaf ports (not depended on), but most of the installed ports are > in the "middle," > where they are depended on by something else, and most of those have > dependencies of their > own. It would be a SMOP to have portmaster track the ports that are "safe" to > upgrade in > parallel. Then of course you have to keep track of your child processes, > create a queue for > what ports to run next, etc. etc. It's all doable of course, but I think the > return on > investment for this project would be very small. Patches are always welcome > however. :) > > > Disadvantages: > > - Moderately difficult to implement. > > *cough*
I have a small script in production, which grabs all dependant ports to compile and does a serial package build, where all required packages are built/installed prior to the next package being built. With some minor additions, I *think* I could make those parallel package builds work without too much fuss. Package upgrade a something different though, but the whole ports framework is flawed in that area anyway ('make package' should come *before* 'make install'). Don't hold your breath though, ENOTIME as always ... Ulrich Spoerlein -- A: Yes. >Q: Are you sure? > >A: Because it reverses the logical flow of conversation. > >>Q: Why is top posting frowned upon? _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"