| 1 |
On 5 August 2015 at 03:09, Davide Pesavento <pesa@g.o> wrote: |
| 2 |
> On Mon, Aug 3, 2015 at 8:59 PM, Ben de Groot <yngwin@g.o> wrote: |
| 3 |
>> On 4 August 2015 at 04:20, Rich Freeman <rich0@g.o> wrote: |
| 4 |
>>> [...] |
| 5 |
>>> Gentoo should be the best of both worlds. We should give users the |
| 6 |
>>> power to tweak things, but we shouldn't force them to play with config |
| 7 |
>>> files all day long just to have a functional system. If users want to |
| 8 |
>>> care we let them care instead of telling them "don't touch" like most |
| 9 |
>>> other distros, but if they don't care we still provide reasonable |
| 10 |
>>> defaults. |
| 11 |
>> |
| 12 |
>> And that is exactly what we do. The kde profile enables qt4, the |
| 13 |
>> plasma profile enables qt5, the other profiles have no qt* useflags |
| 14 |
>> enabled. These are reasonable defaults. |
| 15 |
>> |
| 16 |
> |
| 17 |
> As tetromino pointed out, this is very far from the real current situation. |
| 18 |
|
| 19 |
Indeed, I was wrong here. We will need another solution. |
| 20 |
|
| 21 |
>> Of course some users will proceed to enable both qt4 and qt5 globally |
| 22 |
>> in their make.conf, but I don't think it is unreasonable to expect |
| 23 |
>> them to then deal with adding exceptions to package.use for those |
| 24 |
>> packages where exactly-one-of is required. |
| 25 |
>> |
| 26 |
>> In my opinion, this is the way Gentoo has always worked, and we should |
| 27 |
>> simply recommend users to only set one of the qt* useflags as globally |
| 28 |
>> enabled, if they want to prevent such micro-management. Hiding the qt4 |
| 29 |
>> option is in my opinion the wrong solution around people complaining |
| 30 |
>> after they have consciously enabled both flags. |
| 31 |
>> |
| 32 |
>> If this is not acceptable (or "absolutely unusable" as one dev put |
| 33 |
>> it), then we need a proper solution, which a) will not hide the qt4 |
| 34 |
>> option, and b) will prevent triggering required_use blockage by |
| 35 |
>> choosing qt5 over qt4 in case both are enabled, while c) informing the |
| 36 |
>> user about this. This probably requires new eclass or even EAPI |
| 37 |
>> functionality. |
| 38 |
>> |
| 39 |
> |
| 40 |
> Please go ahead and design and implement such functionality (a sort of |
| 41 |
> REQUIRED_USE defaults). |
| 42 |
|
| 43 |
Something along the lines of PYTHON_TARGETS could work. But |
| 44 |
personally, I'm happy with REQUIRED_USE. |
| 45 |
|
| 46 |
> In the meantime, we will apply the policies |
| 47 |
> written in the Qt project wiki page. |
| 48 |
|
| 49 |
Except for the one that is wrong. |
| 50 |
|
| 51 |
>> In the meantime, we should stick with the policies adopted at the qt3 |
| 52 |
>> to qt4 transition (explicit versioned useflags) and let the user deal |
| 53 |
>> with per-package management if they enable both flags. |
| 54 |
>> |
| 55 |
> |
| 56 |
> We didn't have REQUIRED_USE at the time of the qt3->qt4 transition, so |
| 57 |
> this point is completely moot. |
| 58 |
|
| 59 |
We had something worse. That didn't prevent us from using it tho. |
| 60 |
|
| 61 |
-- |
| 62 |
Cheers, |
| 63 |
|
| 64 |
Ben | yngwin |
| 65 |
Gentoo developer |
Archives