Re: [gentoo-dev] Re: useflag policies

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/08/15 08:58 AM, 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
>
>>>
>>> 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.
>

Why do you need this?

#1, if you really want RDEPEND to only include the deps the package
will actually use, then you do this:

old:

qt5? ( list of qt5 atoms )
qt4? ( list of qt4 atoms )

..to new:

qt5? ( list of qt5 atoms )
!qt5? (
  qt4? ( list of qt4 atoms )
)


BUT I would advise against this.  If a user has specified both qt4 and
qt5 in USE, then I see no problem with the VDB having both qt4 and qt5
atoms listed as dependencies.  End-users that want a clean VDB can
just make sure they only enable one flag, but end-users that don't
care will have packages that just work.


> Leaving constructing of dependencies to developers in all cases
> will cause only pain in your solution.

It really wont, see above.  At minimum, it's barely any more work than
it is with a REQUIRED_USE based solution.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlXKDTkACgkQAJxUfCtlWe09QAD/ST47V7i08k09c8o+dgMx8hQP
cRyBiTzxHKKtQ3aqmKIBAIdjBB4rGZLLMjiu9l0KfUOkOT1J+Z8oHPWQhzDPJpqv
=LCgR
-----END PGP SIGNATURE-----