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 1NqgMf-0004ic-M2 for garchives@archives.gentoo.org; Sun, 14 Mar 2010 05:27:49 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 89AFAE091F; Sun, 14 Mar 2010 05:27:47 +0000 (UTC) Received: from mail-px0-f201.google.com (mail-px0-f201.google.com [209.85.216.201]) by pigeon.gentoo.org (Postfix) with ESMTP id 4207DE08E8 for ; Sun, 14 Mar 2010 05:27:40 +0000 (UTC) Received: by pxi39 with SMTP id 39so1524357pxi.2 for ; Sat, 13 Mar 2010 21:27:39 -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=w9OUhbTe3Gwm+h/df8JobQ1QSo/8OSrxnQf8JYGuknc=; b=eFG05OmQidOTfxrebQoiYGxNWniitaX5zqKW0UI48FGdjVFG/kGS+QviHuZ9dfHCMX UEotmxcNQvxAo9/LB+3ejkSkhr7v6jdAwF6LhTug5mBuq93P5HgwoZK2LCXuFidsGTmP a/OzgfU1bQwABXjjN1ZgDOu/gD7qyDKYzS9Xs= 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=YkxwRV8sV0508NCrRf5OhCfI9F0SASBgGEYF5vYrwetaqEWjsDAHlBRmEdqRnFl9Oc rBJPumG0p81DeNzaBzavbwMjE0l9Ae92abpiQYrfxSjppKRILtbK2pc1ayyJ16WS2zdF 9+IpcZOke4GCciaqsO++uk/ufPVMUuYuOwu2g= Received: by 10.141.91.11 with SMTP id t11mr4628821rvl.78.1268544459730; Sat, 13 Mar 2010 21:27:39 -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 20sm3792487pzk.11.2010.03.13.21.27.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 13 Mar 2010 21:27:38 -0800 (PST) Received: by smtp.gmail.com (sSMTP sendmail emulation); Sat, 13 Mar 2010 21:25:45 -0800 Date: Sat, 13 Mar 2010 21:25:45 -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: <20100314052545.GB17983@hrair> References: <201003041652.56521.tampakrap@gentoo.org> <1268068400.10824.36.camel@localhost> <1268088000.10198.20.camel@lillen> <20100313211615.GA17983@hrair> <1268524966.12656.18.camel@localhost> 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="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline In-Reply-To: <1268524966.12656.18.camel@localhost> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 2410ce23-77a6-4ff1-b7c5-f03605d673c1 X-Archives-Hash: 4c3d2e1adc0937ada0cc2e9876b0601a --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 14, 2010 at 02:02:46AM +0200, Mart Raudsepp wrote: > On Sat, 2010-03-13 at 13:16 -0800, Brian Harring wrote: > > 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. >=20 > What sort of QA affects do you imagine it having? Simple enough. Right now, you change a profile, or want to stable a=20 pkg, you can do a scan and identify all new visibility issues from=20 profiles- you can validate up front that for the list of=20 supported/stable profiles, these changes occur. If things are shifted over to prefering users mixing/matching profiles=20 on their own (meaning we no longer have a gnome amd64 2010 for=20 example), devs no longer get QA warnings when they break stuff for it. Users see it however. > 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. Current QA (repoman/pcheck), if a use flag is defaulted on, it's deps=20 in a pkg must be visible. Via repoman/pcheck, they ensure that the=20 default use configuration for a profile, all visible pkgs dependencies=20 are visible (making the pkg fully usable). Consider mixing/matching gnome/kde with a profile that has quite a few=20 packages masked- say mips. To be clear, this is a hypothetical case-=20 I know it exists, I'm just choosing two likely targets. Say gnome=20 requires some codecs use flag flipped on triggering a dep on a pkg=20 masked for mips. I'm not saying these situations can't be worked around- we already fix=20 them now as they come up. The thing is, whenever you change something=20 now, those profile combinations are validated- with mix/match=20 approach, that validation won't be occuring, the users will be the=20 ones seeing the breakage rather than the dev. > 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). Either you're suggesting that repoman/pcheck would have to scan all=20 arbitrary combinations of gnome/kde/desktop w/ misc arches, or you=20 need to be a fair bit more precise about how QA tools would identify=20 what profile combinations to check. If you're proposing that the QA tool arbitrarily combines arches w/=20 various desktop/server mixins, I'll again note that the run time of=20 visibility scans is directly related to # of profiles to check- for=20 example, removal of mips profiles from profiles.desc is if memory=20 serves me a ~33% reduction in visibility runtime for pcheck. For repoman (which all devs have to use for commiting), # of profiles=20 is even more of a critical value performance wise. > 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? Issues will exist regardless of what the combination is. The point=20 I'm making is that with the current model, we catch those issues prior=20 to commit- having users mix/match on their own means users will see=20 those issues rather than devs. Literally, they'll see the breakage. ~harring --Fba/0zbH8Xs+Fj9o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAkucc1kACgkQsiLx3HvNzgfvHgCeO58/RsPfMZpQwgpsBHegv8zJ BhwAoKJ1ZAg2ngbMSGb8aElQX75YRciU =VWMI -----END PGP SIGNATURE----- --Fba/0zbH8Xs+Fj9o--