Date: Tue, 20 Mar 2007 22:57:37 -0700 From: Garrett Cooper <youshi10@u.washington.edu> To: freebsd-ports@freebsd.org Subject: Re: A review of different port management tools : analysis for Google SoC project Message-ID: <4600C951.3080708@u.washington.edu> In-Reply-To: <20070321050535.GB68447@thought.org> References: <4600AC05.4000004@u.washington.edu> <20070321050535.GB68447@thought.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Gary Kline wrote: > On Tue, Mar 20, 2007 at 08:52:37PM -0700, Garrett Cooper wrote: >> Hi all, >> I know this may be more of a questions@ type of question, but I was >> wondering if some people could provide me with short history (beyond the >> last 3 months) and the tipping points of portmaster vs the portupgrade, >> portinstall, etc tools. >> I know portmaster is a bourne shell script and the portupgrade, >> portinstall, etc scripts are ruby based, so that's a given. >> I just want to know if there's a given solution that I could work >> with in improving the ports system and forge into a unified port/pkg >> management frontend (using bourne shell scripts and C), combined with >> the current package management tools in place (pkg_add, pkg_version, >> etc), as part of a Google Summer of Code proposal. > > > > To Garrett and my days-of-yore ports gang, and the maintenance > and build guys, > > How about this idea for integrating into a new ports/package > project: say for people with a fast I686 who wanted -O3 and -pipe > and wanted his packages built remotely rather than his own > computer. Would be be posssible to build a package, custom > (according to one's /etc/make.conf) on FreeBSD's servers, then > fetch the *tgz package back? Kernels, and worlds would reside > on the remote server for only a few hours before being > automatically cleansed. This would be super for everything from > a i486-166MHz with 32Megs that was serving mail *only*, a slow > to moderate i686, or even an AMD 2800. Building locally is > sometimes the only way. But if users have slower servers and > there are no current packages (i386), why not let the builds be > queued? > > (Please 'cuse me if this is too wild, but I just had a full > double espresso and am bubbling over with ideas.) > > gary > > > > >> Thank you very much for your help in trying to make a great OS even >> better. >> -Garrett Eh, it's a wishful thought but unfortunately everyone has a large list of dependencies that will (most likely) differ from the rest of the bunch, from languages, to options, to library versions -- doing that wouldn't be unfeasible. However, if you want a faster method to compiling stuff, there's distcc. It's not exactly the best thing to use all the time, but if you work with port maintainers and stuff gets more standardized, distcc can be an effective way to building packages across multiple machines. Apart from that, there isn't much way to do anything... apart from setting up your own higher powered PC with a set of your desired options and build from within jails, and package as you go. A i386 can build different archs binaries (amd64, ppc, etc), in-so-much as it can find the right info (headers, libraries to link against, etc). That's a thought for your PCs project :). -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4600C951.3080708>