From owner-freebsd-ports Sun Sep 28 22:44:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA18742 for ports-outgoing; Sun, 28 Sep 1997 22:44:43 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA18736 for ; Sun, 28 Sep 1997 22:44:37 -0700 (PDT) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id PAA13664; Mon, 29 Sep 1997 15:14:27 +0930 (CST) Message-ID: <19970929151427.43719@lemis.com> Date: Mon, 29 Sep 1997 15:14:27 +0930 From: Greg Lehey To: "Jordan K. Hubbard" Cc: ports@FreeBSD.ORG Subject: Re: Uh oh.. Time to take another look at the packages collection! References: <8460.875510079@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <8460.875510079@time.cdrom.com>; from Jordan K. Hubbard on Sun, Sep 28, 1997 at 10:14:39PM -0700 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-ports@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, Sep 28, 1997 at 10:14:39PM -0700, Jordan K. Hubbard wrote: > The FreeBSD-current packages collection currently requires 713MB, not > counting the filename information itself (which, on CDs, is stored > very wastefully and generally accounts for another 30-40MB in cases > like this where you have hundreds of files). I don't need to tell > anyone here that 750MB does *not* fit on a single CD, and even with > 4 CDs for 3.0 we're going to run into problems just organizing it. > > So, as I see it, we have two alternatives: > > 1. Come up with a "reduced set" of packages which we'll provide that > way, the goal being to provide 650MB or less of "quality" packages > rather than going for the kitchen-sink approach. That way flamewar lies. And if not flamewar, then possibly because only one person knows a certain package, and has decided it's not that hot. He could be wrong. > 2. Come up with a way of splitting the packages collection into multiple > pieces, each piece having its own INDEX file and such. Sounds like the way to go. Is it so difficult? We could go for a purely alphabetical split, or maybe figure out some easily-understood functional split. Whatever we choose should be expandable for the estimated 1.5 GB in 4.0. Greg