On 11/08/15 22:58, Sergey Popov wrote:
> 11.08.2015 15:30, Michael Palimaka пишет:
>> On 11/08/15 20:10, Sergey Popov wrote:
>>> Err, i have read the whole thread and still does not get a point, why i
>>> am wrong.
>>
>> You clearly have not. The reasoning behind Qt team's policy is described
>> on the page and has been reiterated on this list. You are undermining
>> what little confidence there is in the QA team by making decisions with
>> no consultation about problems you do not understand.
>>
>>> It's old battle like we have beforce with "gtk" meaning "any versions of
>>> GTK flag". This behaviour should be killed with fire.
>>>
>>> Let's me reiterate some of the cases:
>>>
>>> 1. Package can be build without Qt GUI at all, but either Qt4 or Qt5 can
>>> be chosen, but not both.
>>>
>>> Fix this with REQUIRED_USE, do not enable any of Qt flags by default
>>
>> Problem: this requires manual intervention if the user has both qt4 and
>> qt5 USE flags enabled.
>>
> 
> User choice of using USE flags is NOT a problem

I invite you to reproduce the problem yourself then make the judgement.
Using REQUIRED_USE like this makes the affected packages unusable.

>>>
>>> 2. Package can not be build without Qt GUI - either Qt4 or Qt5 is
>>> required, but not both
>>>
>>> Same thing here, different REQUIRED_USE operator. But - enable one of
>>> the flags by default to ease life of users.
>>
>> Problem: this requires manual intervention if the user has both qt4 and
>> qt5 USE flags enabled.
> 
> Same here
> 
>>>
>>> 3. Package can be build with Qt4 or Qt5 or both AT THE SAME TIME(if such
>>> package even exists?)
>>>
>>> Do not use REQUIRED_USE here, not needed.
>>>
>>> Now, please tell me, where am i wrong?
>>>
>>
>> The problem is manual intervention is required if the user has both qt4
>> and qt5 USE flags enabled - and this is a common configuration. It is
>> not acceptable to make a user manually add numerous package.use entries
>> when all they want to do is install KDE.
> 
> And here
> 
>> I agree Qt's policy is not a perfect solution, but in the absence of
>> some feature allowing a preference to be set when there is a conflict
>> it's the best we've got.
>>
> 
> If you want to go this way, then please provide helper functions in
> eclasses to set dependencies properly for all common use cases. That
> will ease life both of developers and users.
> 
> Leaving constructing of dependencies to developers in all cases will
> cause only pain in your solution.
> 
> Look at the example with berkdb/gdbm, that i have posted recently.
> 
> If both of flags are not set - we stick to default.
> Should this be set in EVERY ebuild explicitly?
> 
> Maybe provide some sugar like $(qt_use_default qtgui 5), where
> qt_use_default is the name of function, qtgui is the package and 5 is
> the slot for default choice, where either BOTH of flags(qt4, qt5) are
> enabled or disabled

How does this solve the REQUIRED_USE problem? Or is your only objection
is that resulting dependency string is "too hard"?

Don't forget that as a project with no special authority, Qt's policy
remains a suggestion for the vast majority of maintainers. If someone
wishes to provide support for only one Qt version or abuse their users
with REQUIRED_USE they are still free to do so.


Reply via email to