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 ) id 1NqYjA-000735-OV for garchives@archives.gentoo.org; Sat, 13 Mar 2010 21:18:32 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7FD5CE0B2E; Sat, 13 Mar 2010 21:18:27 +0000 (UTC) Received: from mail-pw0-f53.google.com (mail-pw0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 88584E0A4A for ; Sat, 13 Mar 2010 21:18:10 +0000 (UTC) Received: by pwj3 with SMTP id 3so1211556pwj.40 for ; Sat, 13 Mar 2010 13:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=w5vMccgHUEbt04B8JcHCV8JuYtGUzmnvGQFB8OIpMjM=; b=V3OCEX8o/NJUJCbiINVQkLTMjvhrDSpcamunH9wujxfXhVuhOouoeijZY+6uRvYK74 m2bt4zAd8d0MAINAYQo88JvhDq9kYFudEL27oUUO47hNDCVaaLYiX17rlEgMh5RtCX0k DMC0Ul3R/2YmciwGUmkV4/QF2BsYt/zO27uPY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=clfWD4LM48O1itFGvW/kG9a2HzxeUnArQ4SCjAEIQZnXOHJsa4j316PQ7JarDAQ6tU MLAWeu86AsPtcvigX1hTugrIjn4g+Jo4BDZy0nJvOIF+yuHX+iGDgywKoa1FSaLqcvnz c+TRQtiTeM5/rW4blIDfLF4Eb/vddCo7uF11Q= Received: by 10.141.2.2 with SMTP id e2mr97782rvi.274.1268515090097; Sat, 13 Mar 2010 13:18:10 -0800 (PST) Received: from smtp.gmail.com (c-67-171-128-62.hsd1.wa.comcast.net [67.171.128.62]) by mx.google.com with ESMTPS id 23sm3226021pzk.10.2010.03.13.13.18.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 13 Mar 2010 13:18:08 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Sat, 13 Mar 2010 13:16:15 -0800 Date: Sat, 13 Mar 2010 13:16:15 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Reorganizing handling of target specific profiles (Was: Split desktop profile patches & news item for review) Message-ID: <20100313211615.GA17983@hrair> References: <201003041652.56521.tampakrap@gentoo.org> <1268068400.10824.36.camel@localhost> <1268088000.10198.20.camel@lillen> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <1268088000.10198.20.camel@lillen> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 1dcc92bf-a5c7-46f9-aa0d-ed0424b1f011 X-Archives-Hash: 56d8bd5fd0d974badd855e4e9145a7fc --wac7ysb48OaltWcw Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 fashion, > > 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 interesting > 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 to > date with which hardened-compilers are currently masked/unmasked. 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. 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. 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 --wac7ysb48OaltWcw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAkucAJ8ACgkQsiLx3HvNzgdfoQCfVviMdNbYMjLZZ5Xp0ViQ/9yO 7FYAn3LOkHt5bEFV30/9ttyiAotETXR2 =YdSc -----END PGP SIGNATURE----- --wac7ysb48OaltWcw--