From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from <gentoo-dev+bounces-40046-garchives=archives.gentoo.org@lists.gentoo.org>) id 1NqbIw-0006Zl-0K for garchives@archives.gentoo.org; Sun, 14 Mar 2010 00:03:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CF5C4E09AB; Sun, 14 Mar 2010 00:03:34 +0000 (UTC) Received: from smtp-out.neti.ee (smtp-out.neti.ee [194.126.126.41]) by pigeon.gentoo.org (Postfix) with ESMTP id E6EDEE08EC for <gentoo-dev@lists.gentoo.org>; Sun, 14 Mar 2010 00:03:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by relay212.estpak.ee (Postfix) with ESMTP id 2E4062B68399B for <gentoo-dev@lists.gentoo.org>; Sun, 14 Mar 2010 02:03:21 +0200 (EET) X-Virus-Scanned: amavisd-new at estpak.ee Received: from smtp-out.neti.ee ([127.0.0.1]) by localhost (relay212.estpak.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JB3SEM6sxdFN for <gentoo-dev@lists.gentoo.org>; Sun, 14 Mar 2010 02:03:18 +0200 (EET) Received: from NETI-Relayhost2.estpak.ee (neti-relayhost2.estpak.ee [88.196.174.199]) by relay212.estpak.ee (Postfix) with ESMTP id 6367E2B683973 for <gentoo-dev@lists.gentoo.org>; Sun, 14 Mar 2010 02:03:18 +0200 (EET) X-SMTP-Auth-NETI-Businessmail: no Subject: Re: [gentoo-dev] Re: Reorganizing handling of target specific profiles (Was: Split desktop profile patches & news item for review) From: Mart Raudsepp <leio@gentoo.org> To: gentoo-dev@lists.gentoo.org In-Reply-To: <20100313211615.GA17983@hrair> References: <201003041652.56521.tampakrap@gentoo.org> <1268068400.10824.36.camel@localhost> <1268088000.10198.20.camel@lillen> <20100313211615.GA17983@hrair> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1+m5fJyUCTQ6jb9npZi5" Date: Sun, 14 Mar 2010 02:02:46 +0200 Message-Id: <1268524966.12656.18.camel@localhost> Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-Archives-Salt: ef76a34e-b859-484e-a47c-90cd25a23ea9 X-Archives-Hash: 08f14e60df0b44ff7b05a25dd7702cd0 --=-1+m5fJyUCTQ6jb9npZi5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, 2010-03-13 at 13:16 -0800, Brian Harring wrote: > On Mon, Mar 08, 2010 at 11:40:00PM +0100, Peter Hjalmarsson wrote: > > m=E5n 2010-03-08 klockan 19:13 +0200 skrev Mart Raudsepp: > >=20 > > > Instead I think we should be improving "eselect profile" to support > > > multiple inheriting /etc/make.profile files in a user friendly fashio= n, > > > and in the end removing 249 subprofiles, instead of adding 28+. > > >=20 > >=20 > >=20 > > I vote for this one. A profile being a only contains what is interestin= g > > for that profile, and you can "stash together" some profiles into your > > own cocktail. > > Yeah, I know it sounds horrible, but it would still be better then to > > only be able to focus on one small set. > >=20 > > For example if I am using the GNOME DE, and have someone other also > > using my computer, but who really wants to use KDE. Should I have to > > find out what from the KDE profile to enable in my env to make my > > GNOME-profile also tingle for KDE? > >=20 > > I think having a set of "base profiles" for toolchains and alike (i.e. > > default, hardened) would be good. Then be able to add for example > > desktop/gnome or server and/or selinux profiles on top would be > > interesting. This also for maintainers, as for example PeBenito can > > focus on the selinux part of the profiles, and do not have to keep up t= o > > date with which hardened-compilers are currently masked/unmasked. >=20 > While I agree in principle within mixins, no one here is discussing=20 > the QA affect of it- right now we can do visibility scans of=20 > combinations of gnome + amd64 + 2010 because they're defined. What sort of QA affects do you imagine it having? Though I'm talking in the context of what I proposed - using it for just the target profiles that only tweak USE flags and other such defaults, nothing else. I considered QA affects for that case, at least in my own thoughts. I think QA would be checked anyhow there, as part of all USE flags enabled assumpting testing or static testing of various USE flag combinations of a package (e.g, for statically finding circular dependencies or the like). If you put selinux and toolchains in the mix, that indeed could be problematic to QA. Though one could probably define some profiles somewhere that would get used for QA testing, but not exposed to users. Do you foresee bad QA affects for the for the desktop/developer/gnome/kde/server profiles case too, or just when mixing in selinux/toolchains/etc? > If there is a shift to having users do the combinations themselves=20 > (rather then combining w/in tree), there won't be visibility scans for=20 > it- end result, more broken deps should be able to slide by, more=20 > horked cycles, etc. >=20 > A solution there would be useful- one that preferably doesn't involve=20 > scanning every possible permutation of mixable profiles (you would=20 > *not* like the speed affect that would have on repoman). > ~harring --=20 Mart Raudsepp Gentoo Developer Mail: leio@gentoo.org Weblog: http://blogs.gentoo.org/leio --=-1+m5fJyUCTQ6jb9npZi5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (GNU/Linux) iEYEABECAAYFAkucJ6YACgkQkeYb6olFHJclfwCfe+v5uNDETIGVx3LCqK5SPp5f daoAoIHgvVJVpHEsbI9Iy/q8XsmSyn5u =reP7 -----END PGP SIGNATURE----- --=-1+m5fJyUCTQ6jb9npZi5--