Date: Thu, 18 Nov 2004 06:29:44 +1000 (EST) From: jason andrade <jason@rtfmconsult.com> To: Kris Kennaway <kris@obsecurity.org> Cc: hubs@freebsd.org Subject: Re: freebsd 5.3-release and some observations Message-ID: <Pine.LNX.4.60.0411180622020.29442@luna.rtfmconsult.com> In-Reply-To: <20041117160330.GA71815@xor.obsecurity.org> References: <Pine.LNX.4.60.0411171512011.29442@luna.rtfmconsult.com> <20041117160330.GA71815@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.60.0411180622020.29442>