Date: Mon, 15 May 2006 17:05:58 +0800 From: Adrian Pavone <apavone@eftel.com> Cc: ports@freebsd.org, "freebsd-questions@FreeBSD. ORG" <freebsd-questions@freebsd.org> Subject: Re: Has the port collection become to large to handle. Message-ID: <44684476.2030901@eftel.com> In-Reply-To: <008b01c677fb$c99b4290$b3db87d4@multiplay.co.uk> References: <446786CF.6050807@fromley.net><MIEPLLIBMLEEABPDBIEGGEALHHAA.fbsd@a1poweruser.com> <3aaaa3a0605141906k2622e9dawe7e9bf7def72167@mail.gmail.com> <008b01c677fb$c99b4290$b3db87d4@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Steven Hartland wrote: > Chris wrote: > >> On 15/05/06, fbsd <fbsd@a1poweruser.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44684476.2030901>