Gentoo Archives: gentoo-dev

From: Jason Stubbs <jstubbs@g.o>
To: gentoo-dev@l.g.o
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 12:55:58
In Reply to: Re: [gentoo-dev] Dirt: To shove under the rug or not shove under the rug? (aka another round of USE_EXPAND) by "Diego 'Flameeyes' Pettenò"
1 Before you reply to this.. Can you enlighten me on what the solution to the
2 problem is that you are heading toward? I'm having trouble seeing what your
3 real point is.
5 On Tuesday 27 September 2005 19:41, Diego 'Flameeyes' Pettenò wrote:
6 > On Tuesday 27 September 2005 12:12, Jason Stubbs wrote:
7 > > Which leads me to the one thing I didn't say but feel strongest about..
8 > > What is the real point of USE_EXPAND? What can/does it do that USE flags
9 > > do not?
10 >
11 > They are forced by the profile, as we don't want users to go away WITHOUT
12 > them when they are needed. That's the main part of it.
14 I wasn't referring specifically to the recent profile additions, but to
15 USE_EXPAND in general. However, this is a mis-usage of USE_EXPAND. At least,
16 USE_EXPAND was not designed for this purpose.
18 $ USE="-*" emerge info | grep USE
19 USE="amd64 userland_GNU kernel_linux elibc_glibc"
20 $ USE="-*" KERNEL="" ELIBC="" emerge info | grep USE
21 USE="amd64 userland_GNU"
23 ARCH and USERLAND are the only ones this can't be done for as portage is
24 hardcoded to set them. Thus, they are the only ones you can be guaranteed of.
26 > Then there's the fact that I can test for a generic BSD libc using [[
27 > ${ELIBC} == *BSD ]], too.
29 This would fail in the above case as well. It is not very good for ebuilds to
30 test for the values of arbitrary variables. If some information needs to be
31 passed to ebuilds, there needs to be an explicit contract with portage.
33 > > Similar to "build" and "bootstrap"? Note, these aren't hidden either but
34 > > if the ELIBC and friends should be hidden those should be hidden too.
35 >
36 > But they have sort of meaning to users, for example with newuse, and does
37 > not screw your system around, or at least not completely (one can build a
38 > few packages with build useflag active and still have a working system, at
39 > the end).
40 > Changing the ELIBC/KERNEL/USERLAND is like using a sparc profile on an x86
41 > ...
43 bootstrap - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!
44 build - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!
46 Saying that setting these flags probably won't do much harm to the user's
47 system doesn't mean that they should be exposed.
49 > Also, most ebuilds does not use the above variables in a complete way, they
50 > usually check for a certain content (GNU userland, FBSD libc, Linux
51 > Kernel). Saying for example that kdelibs uses kernel_linux can make people
52 > think that kdelibs works ONLY for Linux kernel, while that's not true at
53 > all. They are special features or workarounds that does not concern users
54 > at all.
56 So what are you really saying? Just that some USE_EXPAND usages shouldn't be
57 exposed to users? That some usages should not be overridable by users?
58 Neither USE_EXPAND or regular USE flags offer either of these features at the
59 moment, other than all USE_EXPAND variables being non-exposed.
61 > > And we're back to USE flags again... ;)
62 >
63 > As they are the only way to change the dependencies, yeah, always USE is
64 > what we need. For the most of the uses, variables are fine, but for
65 > dependency we use them use-expanded.
67 Variables are _not_ fine. I would think it should be clear to everybody by now
68 that ebuilds can not pick random things from the computer they are installing
69 on to define how they will build.
71 # LINGUAS="" emerge kde-i18n | grep '*'
72 * You must define a LINGUAS environment variable that contains a list
73 * of the language codes for which languages you would like to install.
74 * Look at the LANGS variable inside the ebuild to see the list of
75 * available languages.
76 * e.g.: LINGUAS="sv de pt"
78 "Look at the LANGS variable inside the ebuild"!?
79 This is what this thread is about.
81 --
82 Jason Stubbs
84 --
85 gentoo-dev@g.o mailing list