Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Mar 2007 21:05:36 -0800
From:      Gary Kline <kline@tao.thought.org>
To:        Garrett Cooper <youshi10@u.washington.edu>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: A review of different port management tools : analysis for Google SoC project
Message-ID:  <20070321050535.GB68447@thought.org>
In-Reply-To: <4600AC05.4000004@u.washington.edu>
References:  <4600AC05.4000004@u.washington.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
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
> _______________________________________________
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"

-- 
  Gary Kline  kline@thought.org   www.thought.org  Public Service Unix




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070321050535.GB68447>