From owner-freebsd-hubs@FreeBSD.ORG Wed Nov 17 23:20:55 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 A35A516A4CE for ; Wed, 17 Nov 2004 23:20:55 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F0B743D54 for ; Wed, 17 Nov 2004 23:20:55 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B97AF51955; Wed, 17 Nov 2004 15:24:07 -0800 (PST) Date: Wed, 17 Nov 2004 15:24:07 -0800 From: Kris Kennaway To: jason andrade Message-ID: <20041117232407.GA80979@xor.obsecurity.org> References: <20041117160330.GA71815@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: hubs@freebsd.org cc: Kris Kennaway 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 23:20:55 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 18, 2004 at 06:29:44AM +1000, jason andrade wrote: > for example, is it possible to `compress' packages within architectures i= f=20 > there's no problems with running 5.2.1 packages on 5.2 - does that hold f= or > 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. No, they're tied to the release. Often most packages will work, but not all, and not always. The point of keeping package sets for the releases are because they've undergone QA during the release, and users know they'll always work. Note that the release trees are static, so they're a once-only download. > >If at all possible, yes. Mirrors are most useful when they're > >complete mirrors. >=20 > 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. >=20 > 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. In theory, you can always prioritise your updates so that e.g. i386 is always synced when it changes, but ia64 is not synced more than once a month. I don't know how easy this would be to do automatically on the mirror end, or if more infrastructure support would be needed, but that's out of my area. Kris --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBm92XWry0BWjoQKURAjWoAKChcKNkJGiatuS7zYONaYLb+XBWogCeMaJX NmuLqEIm3uBiIzsp3ZVYT0c= =Py93 -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o--