1 |
11.08.2015 15:30, Michael Palimaka пишет: |
2 |
> On 11/08/15 20:10, Sergey Popov wrote: |
3 |
>> Err, i have read the whole thread and still does not get a point, why i |
4 |
>> am wrong. |
5 |
> |
6 |
> You clearly have not. The reasoning behind Qt team's policy is described |
7 |
> on the page and has been reiterated on this list. You are undermining |
8 |
> what little confidence there is in the QA team by making decisions with |
9 |
> no consultation about problems you do not understand. |
10 |
> |
11 |
>> It's old battle like we have beforce with "gtk" meaning "any versions of |
12 |
>> GTK flag". This behaviour should be killed with fire. |
13 |
>> |
14 |
>> Let's me reiterate some of the cases: |
15 |
>> |
16 |
>> 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can |
17 |
>> be chosen, but not both. |
18 |
>> |
19 |
>> Fix this with REQUIRED_USE, do not enable any of Qt flags by default |
20 |
> |
21 |
> Problem: this requires manual intervention if the user has both qt4 and |
22 |
> qt5 USE flags enabled. |
23 |
> |
24 |
|
25 |
User choice of using USE flags is NOT a problem |
26 |
|
27 |
>> |
28 |
>> 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is |
29 |
>> required, but not both |
30 |
>> |
31 |
>> Same thing here, different REQUIRED_USE operator. But - enable one of |
32 |
>> the flags by default to ease life of users. |
33 |
> |
34 |
> Problem: this requires manual intervention if the user has both qt4 and |
35 |
> qt5 USE flags enabled. |
36 |
|
37 |
Same here |
38 |
|
39 |
>> |
40 |
>> 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such |
41 |
>> package even exists?) |
42 |
>> |
43 |
>> Do not use REQUIRED_USE here, not needed. |
44 |
>> |
45 |
>> Now, please tell me, where am i wrong? |
46 |
>> |
47 |
> |
48 |
> The problem is manual intervention is required if the user has both qt4 |
49 |
> and qt5 USE flags enabled - and this is a common configuration. It is |
50 |
> not acceptable to make a user manually add numerous package.use entries |
51 |
> when all they want to do is install KDE. |
52 |
|
53 |
And here |
54 |
|
55 |
> I agree Qt's policy is not a perfect solution, but in the absence of |
56 |
> some feature allowing a preference to be set when there is a conflict |
57 |
> it's the best we've got. |
58 |
> |
59 |
|
60 |
If you want to go this way, then please provide helper functions in |
61 |
eclasses to set dependencies properly for all common use cases. That |
62 |
will ease life both of developers and users. |
63 |
|
64 |
Leaving constructing of dependencies to developers in all cases will |
65 |
cause only pain in your solution. |
66 |
|
67 |
Look at the example with berkdb/gdbm, that i have posted recently. |
68 |
|
69 |
If both of flags are not set - we stick to default. |
70 |
Should this be set in EVERY ebuild explicitly? |
71 |
|
72 |
Maybe provide some sugar like $(qt_use_default qtgui 5), where |
73 |
qt_use_default is the name of function, qtgui is the package and 5 is |
74 |
the slot for default choice, where either BOTH of flags(qt4, qt5) are |
75 |
enabled or disabled |
76 |
|
77 |
-- |
78 |
Best regards, Sergey Popov |
79 |
Gentoo developer |
80 |
Gentoo Desktop Effects project lead |
81 |
Gentoo Quality Assurance project lead |
82 |
Gentoo Proxy maintainers project lead |