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--