From owner-freebsd-ports@FreeBSD.ORG Wed Mar 21 05:57:42 2007 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DA0D16A406 for ; Wed, 21 Mar 2007 05:57:42 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by mx1.freebsd.org (Postfix) with ESMTP id 48CEF13C4DD for ; Wed, 21 Mar 2007 05:57:42 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2L5vfL2025592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 20 Mar 2007 22:57:41 -0700 X-Auth-Received: from [192.168.10.41] (c-67-187-172-183.hsd1.ca.comcast.net [67.187.172.183]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2L5vePZ029347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 20 Mar 2007 22:57:41 -0700 Message-ID: <4600C951.3080708@u.washington.edu> Date: Tue, 20 Mar 2007 22:57:37 -0700 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.10 (X11/20070316) MIME-Version: 1.0 To: freebsd-ports@freebsd.org References: <4600AC05.4000004@u.washington.edu> <20070321050535.GB68447@thought.org> In-Reply-To: <20070321050535.GB68447@thought.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.20.224934 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: A review of different port management tools : analysis for Google SoC project X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2007 05:57:42 -0000 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