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 1EKF01-0007UE-M1 for garchives@archives.gentoo.org; Tue, 27 Sep 2005 12:55:58 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id j8RCleA1031455; Tue, 27 Sep 2005 12:47:40 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 j8RCi5pn028075 for ; Tue, 27 Sep 2005 12:44:05 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 1EKEvJ-0001mM-VR for gentoo-dev@lists.gentoo.org; Tue, 27 Sep 2005 12:51:06 +0000 Received: by opteron246.suzuki-stubbs.home (Postfix, from userid 1000) id 9357D248D4A; Tue, 27 Sep 2005 21:51:17 +0900 (JST) From: Jason Stubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [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 21:51:17 +0900 User-Agent: KMail/1.8.91 References: <200509271823.25788.jstubbs@gentoo.org> <200509271912.22758.jstubbs@gentoo.org> <200509271242.05438@enterprise.flameeyes.is-a-geek.org> In-Reply-To: <200509271242.05438@enterprise.flameeyes.is-a-geek.org> 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="utf-8" Content-Disposition: inline Message-Id: <200509272151.17297.jstubbs@gentoo.org> X-MIME-Autoconverted: from quoted-printable to 8bit by robin.gentoo.org id j8RCi5pn028075 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id j8RCleBb031455 X-Archives-Salt: a4ab666f-83e6-454a-810d-6a4c4206c5c9 X-Archives-Hash: 81bce32deb6dfbcda81e746a64d01c53 Before you reply to this.. Can you enlighten me on what the solution to t= he=20 problem is that you are heading toward? I'm having trouble seeing what yo= ur=20 real point is. On Tuesday 27 September 2005 19:41, Diego 'Flameeyes' Petten=C3=B2 wrote: > On Tuesday 27 September 2005 12:12, Jason Stubbs wrote: > > Which leads me to the one thing I didn't say but feel strongest about= .. > > What is the real point of USE_EXPAND? What can/does it do that USE fl= ags > > do not? > > They are forced by the profile, as we don't want users to go away WITHO= UT > them when they are needed. That's the main part of it. I wasn't referring specifically to the recent profile additions, but to=20 USE_EXPAND in general. However, this is a mis-usage of USE_EXPAND. At lea= st,=20 USE_EXPAND was not designed for this purpose. $ USE=3D"-*" emerge info | grep USE USE=3D"amd64 userland_GNU kernel_linux elibc_glibc" $ USE=3D"-*" KERNEL=3D"" ELIBC=3D"" emerge info | grep USE USE=3D"amd64 userland_GNU" ARCH and USERLAND are the only ones this can't be done for as portage is=20 hardcoded to set them. Thus, they are the only ones you can be guaranteed= of. > Then there's the fact that I can test for a generic BSD libc using [[ > ${ELIBC} =3D=3D *BSD ]], too. This would fail in the above case as well. It is not very good for ebuild= s to=20 test for the values of arbitrary variables. If some information needs to = be=20 passed to ebuilds, there needs to be an explicit contract with portage. > > Similar to "build" and "bootstrap"? Note, these aren't hidden either = but > > if the ELIBC and friends should be hidden those should be hidden too. > > But they have sort of meaning to users, for example with newuse, and do= es > not screw your system around, or at least not completely (one can build= a > few packages with build useflag active and still have a working system,= at > the end). > Changing the ELIBC/KERNEL/USERLAND is like using a sparc profile on an = x86 > ... bootstrap - !!internal use only!! DO NOT SET THIS FLAG YOURSELF! build - !!internal use only!! DO NOT SET THIS FLAG YOURSELF! Saying that setting these flags probably won't do much harm to the user's= =20 system doesn't mean that they should be exposed. > Also, most ebuilds does not use the above variables in a complete way, = they > usually check for a certain content (GNU userland, FBSD libc, Linux > Kernel). Saying for example that kdelibs uses kernel_linux can make peo= ple > think that kdelibs works ONLY for Linux kernel, while that's not true a= t > all. They are special features or workarounds that does not concern use= rs > at all. So what are you really saying? Just that some USE_EXPAND usages shouldn't= be=20 exposed to users? That some usages should not be overridable by users?=20 Neither USE_EXPAND or regular USE flags offer either of these features at= the=20 moment, other than all USE_EXPAND variables being non-exposed. > > And we're back to USE flags again... ;) > > As they are the only way to change the dependencies, yeah, always USE i= s > what we need. For the most of the uses, variables are fine, but for > dependency we use them use-expanded. Variables are _not_ fine. I would think it should be clear to everybody b= y now=20 that ebuilds can not pick random things from the computer they are instal= ling=20 on to define how they will build. # LINGUAS=3D"" emerge kde-i18n | grep '*' * You must define a LINGUAS environment variable that contains a list * of the language codes for which languages you would like to install. * Look at the LANGS variable inside the ebuild to see the list of * available languages. * e.g.: LINGUAS=3D"sv de pt" "Look at the LANGS variable inside the ebuild"!? This is what this thread is about. -- Jason Stubbs --=20 gentoo-dev@gentoo.org mailing list