From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12088 invoked by uid 1002); 20 Nov 2002 16:00:53 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 12079 invoked from network); 20 Nov 2002 16:00:52 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Toby Dickenson Reply-To: tdickenson@geminidataloggers.com To: "Riyad Kalla" , Date: Wed, 20 Nov 2002 16:00:08 +0000 User-Agent: KMail/1.4.3 References: <002a01c290a3$2cd39d10$d628c480@rsk> In-Reply-To: <002a01c290a3$2cd39d10$d628c480@rsk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200211201600.08126.tdickenson@devmail.geminidataloggers.co.uk> Subject: Re: [gentoo-dev] Release/Stable/Dev X-Archives-Salt: 00526809-aba7-410c-b5f7-80852ff0a4a3 X-Archives-Hash: 517ff124238359b04bbd91499cc03881 On Wednesday 20 November 2002 2:43 pm, Riyad Kalla wrote: > This is more of a "how does this work" question: > > I notice so much activity on this list all the time with new packages > and new ideas and new ebuilds, etc. etc... And I realize that the idea > of a "release version" of Gentoo isn't the same as RedHat or Mandrake > where there is a snapshot in time of a code base that is deemed a > "release", its sort of this every-growing and changing repository of > ebuilds. > > This is cool and everything, but it also makes it hard for people that > need to get a "stable release quality" version to say slap on a > production server... So for example, if I download Gentoo 1.4, and > install it today, and my coworker downloads gentoo 1.4 and installs it = 2 > weeks from now, we *might* have different systems cause when he emerged > his original system, some of the packages had changed... (is this an > accurate assessment?) > > How do I combat this? Say if I'm interested in a rock-solid snapshot of > Gentoo without going through an ungodly amount of administrative setup > and mirroring of the snapshot etc.? The administrative overhead of doing this is small, and well worth the ef= fort. 1. use rsync to take a copy of today's portage into a directory on one of= your=20 servers. In this example I use /var/mirror/portage-stable. 2. create an /etc/rsync.d like the one below, and run rsync --deamon. 3. on every other stable server, change their make.conf to include: SYNC=3D"rsync://my.local.rsync.server/portage-stable 4. you probably also should set up a distfiles archive, so that you can s= till=20 install old things when the real portage has moved on. 5. I am still uncertain about the best way to handle critical updates to = these=20 stable systems. Currently I have a seperate rsync mirror which contains a= =20 PORTDIR_OVERLAY directory. That contains copies of ebuilds from the real=20 portage. my /etc/rsync.d is: pid file =3D /var/run/rsyncd.pid timeout =3D 150 [gentoo-portage-stable] path =3D /var/mirror/portage comment =3D Gentoo Portage Tree [gentoo-portage] path =3D /var/mirror/portage-stable comment =3D Stable Snapshot of Gentoo Portage Tree -- gentoo-dev@gentoo.org mailing list