From owner-freebsd-hubs@FreeBSD.ORG Wed Nov 17 20:29:47 2004 Return-Path: Delivered-To: freebsd-hubs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D02D016A4CE for ; Wed, 17 Nov 2004 20:29:47 +0000 (GMT) Received: from luna.rtfmconsult.com (luna.rtfmconsult.com [202.83.72.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54E8343D1F for ; Wed, 17 Nov 2004 20:29:47 +0000 (GMT) (envelope-from jason@rtfmconsult.com) Received: from luna (luna [202.83.72.190]) by luna.rtfmconsult.com (Postfix) with ESMTP id E2C6D5040E; Thu, 18 Nov 2004 06:29:44 +1000 (EST) Date: Thu, 18 Nov 2004 06:29:44 +1000 (EST) From: jason andrade To: Kris Kennaway In-Reply-To: <20041117160330.GA71815@xor.obsecurity.org> Message-ID: References: <20041117160330.GA71815@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: hubs@freebsd.org Subject: Re: freebsd 5.3-release and some observations X-BeenThere: freebsd-hubs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD Distributions Hubs: mail sup ftp List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 20:29:48 -0000 On Wed, 17 Nov 2004, Kris Kennaway wrote: >> given the length of time for package tree updates i'd be >> asking if there is any thoughts that could be raised about >> how better to supply package trees so they aren't `tied' >> to an architecture and thus appear to be released in 3-5G >> chunks. > > package trees are absolutely tied to an architecture, because they > contain compiled files that will only run on that architecture (modulo > things like amd64-i386 compatibility). sigh, i should have been more precise, what i meant was $ARCH/$VERSION. for example, is it possible to `compress' packages within architectures if there's no problems with running 5.2.1 packages on 5.2 - does that hold for 5.2 packages on 5.3 or 5.1 ? you'd then end up with a package tree of say FreeBSD5 with only minor version specific releases. i'm only throwing this up as a future suggestion - i can understand if the package build methodology and QA means that it's easier to stick with the current system that works.. > a bit less frequently because the builds take longer. Note that 4.x > and 5.x builds are usually incremental builds thesedays, meaning that > if the package doesn't change it isn't changed on the server, thus > reducing mirror download bulk. that's pretty cool. i should start doing some stats to measure the actual rate of change in the archive. thanks ken, more work :-) >> should mirrors carry this ? > > If at all possible, yes. Mirrors are most useful when they're > complete mirrors. nod, i'm just balancing that against updating (relatively) large data sets that may not get used that much and/or it takes a while to update. in particular as the number of architectures grow then mirroring every -current package tree could result in quite a large update to all mirrors without a corresponding benefit - say 6 archs by 3G each is 18G/week in updates. regards, -jason