From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15031 invoked from network); 10 Aug 2004 18:47:34 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 10 Aug 2004 18:47:34 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1Buben-0005oR-ED for arch-gentoo-dev@lists.gentoo.org; Tue, 10 Aug 2004 18:47:33 +0000 Received: (qmail 608 invoked by uid 89); 10 Aug 2004 18:47:33 +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 6346 invoked from network); 10 Aug 2004 18:47:32 +0000 From: Chris Gianelloni Reply-To: wolf31o2@gentoo.org To: gentoo-dev@lists.gentoo.org In-Reply-To: <20040810200552.7af65f6d.spider@gentoo.org> References: <20040808185144.GB29077@mail.lieber.org> <200408090104.50263.absinthe@gentoo.org> <20040809095214.GJ29077@mail.lieber.org> <1092061268.30233.18.camel@localhost> <20040810000107.GX29077@mail.lieber.org> <20040810200552.7af65f6d.spider@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-YY6hlgf+ei92dtOrfUnv" Organization: Gentoo Linux Message-Id: <1092164618.21441.104.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 10 Aug 2004 15:03:39 -0400 Subject: Re: [gentoo-dev] GLEP 19, reloaded (again) X-Archives-Salt: b79dd86c-816a-4db1-bd02-ec68e52fec68 X-Archives-Hash: a673130e8be5ee308dd5fed971a7eb5c --=-YY6hlgf+ei92dtOrfUnv Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-08-10 at 14:05, Spider wrote: > begin quote > On Tue, 10 Aug 2004 00:01:07 +0000 > Kurt Lieber wrote: >=20 > > One think that I think *everyone* agrees on is that any stable tree > > needs to be regularly updated with security fixes. With this in mind, > > I'm concerned with trying to maintain multiple separate SYNC modules.=20 > > We'd have to upgrade each one with every GLSA, thus doubling or > > tripling the amount of CVS work needed each time. >=20 > Once again, coming from an ISV standpoint where we would have loved to > use Gentoo (or, I would, some of the people wouldn't care, and one or > two i'd have to beat to make them bend to my will, but whatever ;)=20 >=20 > We had to scrap both Gentoo -and- Debian stable trees. Why? Because > both update the -main- repository when releasing security fixes/ > bugfixes. Neither have a stable tree thats archived once and never > changes. I have no problem with that at all, and this is really more what I would like to see. The only reason I was mentioning using ~arch as a method for security updates was to quell the people asking about security updates. > If you have to actively change a tree (modifications directly into the > "frozen" tree) which is the case in many environmens, you get stuck with > this problem. if upstream ever changes their tree, work is lost. You can > separate local trees and so on, however, once again work is lost when > internal revisions have superceeded the ones in the tree. (fex, local > changes to sshd to patch ther initscripts and default config files > before rollout, which ups the revision of openssh a few times, and then > there is a backported securityfix? It won't get merged. ) >=20 > this is why I'd like to push, once more, for separated "stable" (frozen > snapshot basically) and "updates" pushed in a separate repo. If we > want others to use this in enterprise, we have to make it easy for them. > :-) To accomplish this would require a change to portage, but I think it could be done with minimal work. Allow me to ramble... *grin* We add something along the lines of a PORTAGE_TREE variable, that can be set to either the release version, or to "current". So you would have for 2005.0 something like: PORTAGE_TREE=3D"2005.0" in make.conf (actually, in make.profile/make.defaults). When this is set to something non-"current", then portage will rsync *only* the 2005.0 directory in the "gentoo-updates" module, which goes to an updates directory under /usr/portage, which is just an overlay which is added due to being non-"current". The rest of the tree is *never* synched when an emerge sync is done. When PORTAGE_TREE=3D"current", the overlay doesn't exist, and the tree is synched as normal. Now, this gives us a non-moving, completely frozen tree for installations/QA/whatever and also gives us a mechanism for updates. It requires a little bit more work from the portage developers (whom I am sure are busy enough), but then takes up minimal space on the mirrors and requires the addition of only one rsync module. It also keeps the mirrors from having to process rsync over the entire frozen portion of the tree. --=20 Chris Gianelloni Release Engineering QA Manager/Games Developer Gentoo Linux Is your power animal a penguin? --=-YY6hlgf+ei92dtOrfUnv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBGRwKkT4lNIS36YERAiBoAJsEkl+SAvQeshgnlaNZTYFUyRd/1QCgk1hf w1tvMo234ZLeRCstFOGoel0= =vaMF -----END PGP SIGNATURE----- --=-YY6hlgf+ei92dtOrfUnv--