From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1EKBjA-0005tk-Ga for garchives@archives.gentoo.org; Tue, 27 Sep 2005 09:26:20 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id j8R9If4x030304; Tue, 27 Sep 2005 09:18:41 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id j8R9GFvS002797 for ; Tue, 27 Sep 2005 09:16:15 GMT Received: from zh034158.ppp.dion.ne.jp ([222.3.34.158] helo=opteron246.suzuki-stubbs.home) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1EKBgA-0007UR-RA for gentoo-dev@lists.gentoo.org; Tue, 27 Sep 2005 09:23:15 +0000 Received: by opteron246.suzuki-stubbs.home (Postfix, from userid 1000) id E3DBB248D4A; Tue, 27 Sep 2005 18:23:25 +0900 (JST) From: Jason Stubbs To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Dirt: To shove under the rug or not shove under the rug? (aka another round of USE_EXPAND) Date: Tue, 27 Sep 2005 18:23:25 +0900 User-Agent: KMail/1.8.91 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509271823.25788.jstubbs@gentoo.org> X-Archives-Salt: bf415827-9959-4657-895c-f657527c8700 X-Archives-Hash: 9c114cd09a765578d0534844e154a84d Hello all, To shove under the rug: Bug 62001: Have portage QA checks consider USE_EXPAND Bug 70648: QA warnings about USE_EXPAND-derived use variables Bug 101998: Portage shouldn't warn on missing IUSE for USE_EXPAND To not shove under the rug: Bug 23826: Give more visibility to ebuilds variables (ALSA_CARDS, etc.) Bug 65012: emerge should display USE_EXPAND flags when using --verbose and --pretend (or --ask) The above are only when searching for USE_EXPAND in the summary field. So let's step back a bit and look at the purpose of the QA check first. What it does is check whether an ebuild is utilizing a USE flag that it has not declared. Why does this matter for QA? It means that users are not informed of what options affect the package. It also means the same for portage, which will become more and more important as time goes on. Removing the QA check while the QA problem still exists is, in my mind, just plain ludicrous. Removing the QA check once the QA problem is fixed doesn't make much sense to me either. However, adjusting the check where necessary to match the fix is reasonable. So what needs to be done to fix it? Well, what is the purpose of USE_EXPAND? Put simply, it is to allow the user to select one or more features of a package from a list of choices. How is this different to USE flags? The choices all pertain to one aspect of the package(s). Beyond that is where we start to run into the gray murkiness that has been created due to having no policy on USE_EXPAND. 1) What to do if nothing is set? 2) What to do if an invalid value is set? a) install everything b) install nothing c) install some predefined default d) install some default based on USE flags e) die and tell the user to make a choice 3) How to ebuild behave regarding a USE_EXPAND variable? a) install everything chosen that is valid b) install only the first that is chosen that is valid Of these, 1) and 2) absolutely must be whittled down to one standard. Preferably, 3) should follow one standard as well. Not following one standard will simply lead to users thinking, "but that's not what I wanted..!" It will also lead portage to do needless recompiles due to the information available being limited. Next, storing the information of what choices are valid. If it can be guaranteed that all packages supporting a variable (LINGUAS for example) have exactly the same list of choices in all cases, storing the choice list in a global file is acceptable. If not, each package absolutely must list what choices are available for it. Not doing so means the flow may head into 2) in the above list even when the user has set a valid choice for a different package. Again, it's against the user's expectations. Anybody not caring enough to fix this, please don't respond with "wah! work!?" You've dug your own hole... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list