1 |
On Tuesday 27 September 2005 18:38, Diego 'Flameeyes' Pettenò wrote: |
2 |
> On Tuesday 27 September 2005 11:23, Jason Stubbs wrote: |
3 |
> > So what needs to be done to fix it? Well, what is the purpose of |
4 |
> > USE_EXPAND? Put simply, it is to allow the user to select one or more |
5 |
> > features of a package from a list of choices. How is this different to |
6 |
> > USE flags? The choices all pertain to one aspect of the package(s). |
7 |
> |
8 |
> The way ELIBC, KERNEL, USERLAND are used, is instead something different. |
9 |
> They don't allow users to select what they want, they allow profiles to |
10 |
> declare what they are created for. |
11 |
|
12 |
Which leads me to the one thing I didn't say but feel strongest about.. What |
13 |
is the real point of USE_EXPAND? What can/does it do that USE flags do not? |
14 |
|
15 |
> If some user changes one of these variables, he's *really* screwed up, as |
16 |
> they change quite a few things in the ebuilds (for example, if kernel is |
17 |
> not linux, kdelibs doesn't build support for dnotify, gamin for inotify, |
18 |
> and a few more options in the way). |
19 |
|
20 |
This doesn't quite apply to cross compiling and such, but in general yeah. |
21 |
|
22 |
> I think at least these three variables should be hidden from users, as they |
23 |
> should not mean anything to them. |
24 |
|
25 |
Similar to "build" and "bootstrap"? Note, these aren't hidden either but if |
26 |
the ELIBC and friends should be hidden those should be hidden too. |
27 |
|
28 |
> In alternative, there was the proposal of a use.force file, that would |
29 |
> allow to force some flags on and use that instead of the use-expanded |
30 |
> variables, but currently it doesn't seem to be created and the QA notice |
31 |
> problem is still not solved, those flags should be forced by some profiles |
32 |
> and masked by others, as they are not intended to be changed by users. |
33 |
|
34 |
And we're back to USE flags again... ;) |
35 |
|
36 |
-- |
37 |
Jason Stubbs |
38 |
|
39 |
-- |
40 |
gentoo-dev@g.o mailing list |