1 |
> -----Original Message----- |
2 |
> From: Daniel Robbins [mailto:drobbins@g.o] |
3 |
|
4 |
> > Option 4 I dismiss. If we create USE flags for every shared |
5 |
> library and util |
6 |
> > which might possibly be used by another package, there will |
7 |
> be a hundred |
8 |
> > falgs or more and a user won't be able to take time to |
9 |
> understand the meaning |
10 |
> > of each and decide on setting it or not. |
11 |
> |
12 |
> The solution is to use option 4. As soon as I have the dev |
13 |
> team reorganized, |
14 |
> I'll be adding some much-needed USE upgrades to portage. In |
15 |
|
16 |
If everything is to be a USE variable then things will end up getting |
17 |
unmanageable pretty quickly. Either that or you will have to make tradeoffs |
18 |
between configurability and manageability. |
19 |
|
20 |
For what it's worth, my opinion is that USE variables should apply across |
21 |
the system as system defaults. As Dan pointed out, if you get too many of |
22 |
them then the sheer volume of them will overwhelm even an intermediate user. |
23 |
|
24 |
At the moment the only way to fine tune a package is to tweak the .ebuild. |
25 |
When I created the .ebuild for STLport I decided that I would use the SGI |
26 |
iostream libraries rather than wrappers around the system libraries. That's |
27 |
fine for me, but it might create compatibility problems for your code. Now I |
28 |
guess we could create a SGI_IO USE variable but the only package to which |
29 |
this will be applicable is STLport. Surely an interactive mode or even just |
30 |
command line specified variable would be a better solution. Your average |
31 |
user would not be confronted with any change in user interface, nor would |
32 |
(s)he need to figure a whole whack of obscure USE variables. |
33 |
|
34 |
Another consideration is when there are multiple USE variables from which to |
35 |
choose. |
36 |
|
37 |
Take the case of Qt, GTK+, and Motif. Suppose you have a package that can |
38 |
use any of them (no I don't know of any such packages). You would likely |
39 |
have GTK, QT, and MOTIF all defined as USE variables, but which to use? |
40 |
While an ebuilder can decide an order of preference, we're back to having to |
41 |
like someone else's preferences. Furthermore, while I may prefer Qt for |
42 |
package X, package Y is just so much better with GTK+. |
43 |
|
44 |
Cheers, |
45 |
|
46 |
Sean |
47 |
|
48 |
|
49 |
------------------------------------------------------------------------ |
50 |
Sean Mitchell Software Engineer |
51 |
smitchell@×××××××××××××××××××.com Phoenix Interactive Design Inc |
52 |
tel. 519-679-2913 x237 4th Floor, 137 Dundas St |
53 |
fax. 519 679 6773 London, ON, Canada N6A 1E9 |
54 |
ICQ# 104246806 |
55 |
------------------------------------------------------------------------ |