1 |
On Wednesday 18 July 2001 20:12, you wrote: |
2 |
> On Wed, Jul 18, 2001 at 02:29:40PM +0300, Dan Armak wrote: |
3 |
> > A worse situation: there is no smpeg USE flag. I have 4 options: |
4 |
> > 1. Force usage of smpeg. |
5 |
> > 2. Use smpeg if it's already installed. |
6 |
> > 3. Never use smpeg. |
7 |
> > 4. Create a USE smpeg flag. |
8 |
> > |
9 |
> > Option 4 I dismiss. If we create USE flags for every shared library and |
10 |
> > util which might possibly be used by another package, there will be a |
11 |
> > hundred falgs or more and a user won't be able to take time to understand |
12 |
> > the meaning of each and decide on setting it or not. |
13 |
> |
14 |
> The solution is to use option 4. As soon as I have the dev team |
15 |
> reorganized, I'll be adding some much-needed USE upgrades to portage. In |
16 |
> addition to allowing USE categories, the new USE behavior will allow |
17 |
> certain options to be "on by default". This will allow the system profile |
18 |
> to set "media(smpeg)" on automatically, and it will even be enabled if the |
19 |
> user doesn't have "media(smpeg)" in his USE variable in make.conf. If he |
20 |
> wants to disable it, he'll need to explicitly type "-media(smpeg)". This |
21 |
> will allow us to hide a lot of complex USE variables from the end-user and |
22 |
> keeping the difficult USE work in the system profile. This way, novice |
23 |
> users are much less likely to accidentally disable critical components by |
24 |
> accidentally deleting a USE variable from make.conf. |
25 |
Well, that's certainly better than what there is now :-) |
26 |
|
27 |
> |
28 |
> > There seems no reason to do option 3. Option 2 might seem to be a good |
29 |
> > default, but what about option 1? Is there any good reason not to use |
30 |
> > smpeg, if it takes only 20 mins to d/l and install and adds important |
31 |
> > functionality? If there is, we should create a DONT_USE smpeg flag :-) |
32 |
> |
33 |
> It is fine to force the use of a particular package as long as an |
34 |
> overwhelmingly large percentage of the people would want such functionality |
35 |
> built-in. But, if it's simply an optional component that some people may |
36 |
> not want, it should be configured via a USE variable. |
37 |
|
38 |
I still think there should be optional user-interactive mode. It could print |
39 |
a suggestion based on the USE flags as the default choice, or accept a |
40 |
--silent flag and make all the default choices itself. For detais read the |
41 |
other messages in the thread (some of the replies are out-of-thread, the |
42 |
subject line changed). |
43 |
|
44 |
|
45 |
-- |
46 |
|
47 |
Dan Armak |
48 |
Gentoo Linux Developer |
49 |
Matan, Israel |