From owner-freebsd-ports@FreeBSD.ORG Mon May 15 09:05:57 2006 Return-Path: X-Original-To: ports@freebsd.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4ED116A749 for ; Mon, 15 May 2006 09:05:56 +0000 (UTC) (envelope-from apavone@eftel.com) Received: from tara1.wa.amnet.net.au (tara1.wa.amnet.net.au [203.161.126.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAAEC43D72 for ; Mon, 15 May 2006 09:05:53 +0000 (GMT) (envelope-from apavone@eftel.com) Received: (qmail 18510 invoked by uid 89); 15 May 2006 09:05:51 -0000 Received: by simscan 1.1.0 ppid: 18502, pid: 18503, t: 1.0844s scanners: attach: 1.1.0 clamav: 0.88/m:36/d:1310 spam: 3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on tara1.wa.amnet.net.au X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from unknown (HELO ?192.168.1.65?) (203.161.72.123) by tara1.wa.amnet.net.au with SMTP for ; 15 May 2006 09:05:50 -0000 X-Envelope-To: ports@freebsd.org Message-ID: <44684476.2030901@eftel.com> Date: Mon, 15 May 2006 17:05:58 +0800 From: Adrian Pavone User-Agent: Debian Thunderbird 1.0.2 (X11/20051002) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <446786CF.6050807@fromley.net> <3aaaa3a0605141906k2622e9dawe7e9bf7def72167@mail.gmail.com> <008b01c677fb$c99b4290$b3db87d4@multiplay.co.uk> In-Reply-To: <008b01c677fb$c99b4290$b3db87d4@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, "freebsd-questions@FreeBSD. ORG" Subject: Re: Has the port collection become to large to handle. 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: Mon, 15 May 2006 09:05:59 -0000 Steven Hartland wrote: > Chris wrote: > >> On 15/05/06, fbsd wrote: >> Keep the ports tree how it is, as others have said the size is small >> on modern hard drives and bandwidth trivial, once the initial ports >> tree is in place keeping it up to date needs very little bandwidth and >> its only distfiles that tend to be large, but you only download >> distfiles for ports you install so this is a very good system. If at >> least one person uses a port it is justified and I very much like that >> most tiny apps I search for in the ports tree do indeed exist. How >> would you define commonly used ports? we would end up with a >> favouritism system in place and many arguments about which ports would >> be included in the commonly used group, you also forget that many >> ports that may look meaningless from where you sit are necessary as >> dependants to other ports. > > > There would be not arguments as stats dont lie. Please read the entire > thread there are some good ideas in there which would speed up day to day > use of ports for everyone. Where you get the idea that ports is quick to > maintain is beyond me it takes a good 30mins to sync up if your a few > months out of date now a days. 30mins is not much if you have 1 machine > but add it all up for a large number of machines and its a significant > amount of time which we all could better spend doing other things instead > of waiting for a cvsup to complete. This is why there are options in place that would allow you to download the cvsup to one of you computers, likely a server of some sort, and your other computers all retrieve the CVSup from this local server, significantly speeding up the retrieval time and decreasing the load on the primary servers, a win for everyone. If you have computers of varying architectures or in seperated geographical locations this would not work as worded, but from your wording it sounded like you had a local LAN of computers. Ohh, and for your informations, statistics do lie, that is the point of statistical analysis, which I spent 1 1/2 years of my life studying before changing into my current Software Engineering/Computer Security degree. And, the arguements would arise from the "common" ports/packages directory, a suggestion of fbsd's I believe, whereby common ports that would not be built often primarily due to their size, and so wouldn't show up in statistics (such as Gnome, KDE, OpenOffice, and a number of others), would be placed into a common directory of the ports/packages tree, and would be exempt from these statistics. The arguements would arise over what should be placed into this "common" directory. And what about the case of a port that would be built many times over its lifetime, mainly due to program version changes? The first one that springs to mind would be Firefox. Firefox has had a number of version changes in the same space of time that Exim, a very commonly used mail server application, has been updated, and assuming an even distribution of mail servers and desktop users with firefox, firefox would appear to be 10-20 times more active over it's lifetime. It is also common for people with a desktop computer to format their HDD every 3 months or so, and every time this occured, the desktop PC ports (Xorg, Firefox, KDE/XFCE/GNOME, OpenOffice.org, etc.) would get a rebuild/redownload, again throwing the stastics out of whack. Just my $0.02. Regards, Adrian