From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32756 invoked from network); 20 Jul 2004 21:35:19 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 20 Jul 2004 21:35:19 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1Bn1xT-0005R8-3l for arch-gentoo-dev@lists.gentoo.org; Tue, 20 Jul 2004 21:15:57 +0000 Received: (qmail 14086 invoked by uid 89); 20 Jul 2004 21:14:58 +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 25969 invoked from network); 20 Jul 2004 21:14:57 +0000 From: Olivier Crete To: gentoo-dev@lists.gentoo.org In-Reply-To: <200407201643.25486.absinthe@gentoo.org> References: <20040720131405.GW18023@mail.lieber.org> <200407201643.25486.absinthe@gentoo.org> Content-Type: text/plain; charset=UTF-8 Organization: Gentoo Date: Tue, 20 Jul 2004 17:14:51 -0400 Message-Id: <1090358091.29395.28.camel@montreal> Mime-Version: 1.0 X-Mailer: Evolution 1.5.90 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.5 (---) X-Spam-Report: Spam detection software, running on the system "mx.max-t.internal", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi, The main problem with the profiles approach is that need to keep all of the "old" ebuilds for previous profiles in the tree, unnecessarily bloating the tree and then we have the risk that package maintainers will remove the stable packages after a while by mistake.. [...] Content analysis details: (-3.5 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 1.4 WEIRD_PORT URI: Uses non-standard port number for HTTP Subject: Re: [gentoo-dev] Revisiting GLEP 19 X-Archives-Salt: f867cea5-310d-4eee-8383-e4a4df2b0a84 X-Archives-Hash: 777b0d8fbb13a1679dac7557a56e7b03 Hi, The main problem with the profiles approach is that need to keep all of the "old" ebuilds for previous profiles in the tree, unnecessarily bloating the tree and then we have the risk that package maintainers will remove the stable packages after a while by mistake.. My favorite solution is the portage snapshot + overlay solution. Where the gentoo-stable project makes a snapshot (like we already do on every livecd), it could even be the same snapshot. And then maintain (in a new tree) an overlay with only security fixes. This tree could then be rsynced with gensync (or with a modified portage).=20 Olivier On Tue, 2004-07-20 at 16:43 -0400, Dylan Carlson wrote: > On Tuesday 20 July 2004 9:14 am, Kurt Lieber wrote: > > A while back, I wrote GLEP 19[1] based on some of the needs of the > > gentoo-server project. For various reasons, the GLEP was tabled at the > > time and never went anywhere. A number of folks have expressed an > > interest in revitalizing this GLEP, so I'd like to start a new > > discussion about implementing it. There was a couple of previous > > threads on this GLEP back when it was first introduced that I'll > > include[2] for your reference. >=20 > My thoughts on this are: >=20 > 1/ Many Gentoo users want the ability to update packages for fixes only=20 > (and not just for servers) > 2/ Maintaining separate trees in CVS is probably asking too much of our=20 > current roster, plus requires adding infrastructure and getting everyone=20 > to mirror the new tree(s) > 3/ Users already have a good understanding of what profiles are. This is= =20 > useful. > 4/ Creating separate CVS trees while also using profiles seems superfluou= s. >=20 > Therefore I believe another possible solution is to change the way we use= =20 > profiles (both in practice and in QA policy): >=20 > Implications: >=20 > 1/ archs will need to have a regular, predictable release schedule,=20 > probably at least every six months. > 2/ profiles will list specific package versions whenever possible. e.g.: > =3Dsys-libs/glibc-2.3.2 > 3/ we will need to prepare a list of packages which should not change=20 > unless the user switches profiles. those packages (e.g., toolchain) in=20 > the current, and older profiles do not get updated except for fixes. =20 > 4/ we will need to have a policy about how long we'll support a profile,=20 > and a procedure for end-of-lifing profiles. (probably don't want to=20 > support a single profile for more than 2 years) > 5/ we will need to have documentation for users who are upgrading from on= e=20 > profile to another (upgrade warnings, instructions and considerations) > 6/ repoman will need to be enhanced to check the profiles before removing= =20 > any ebuilds from the tree that might be needed. specific versions pinned= =20 > in profiles need to stay until the profile is changed. >=20 > Potential problems: >=20 > 1/ Makes KEYWORDS redundant > 2/ Unstable (unreleased) profiles will probably, often run into conflicts= =20 > during commit >=20 > I probably missed some things, but it's a start. >=20 > Cheers, > Dylan Carlson [absinthe@gentoo.org] > Public Key: http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x708E1= 65F >=20 > -- > gentoo-dev@gentoo.org mailing list >=20 --=20 Olivier Cr=C3=AAte tester@gentoo.org Gentoo Developer -- gentoo-dev@gentoo.org mailing list